Ні для кого не є секретом, що існує тісна взаємозалежність між розробкою і використанням програмного забезпечення. Саме цим і користується низка практик, що отримали загальну назву DevOps і мають своєю метою допомогти організаціям швидше та якісніше створювати та оновлювати програмні продукти і послуги. Ця методологія зосереджена на узгодженні розробки і постачання програмного забезпечення із його використанням, і це завдання зазвичай вирішується за допомогою автоматизації процесів і стандартизації середовищ розробки з метою забезпечення швидкої підготовки релізів. Публікуємо уривок із нової книжка, перекладеної українською – “Посібник із DevOps” Патрік Дебуа, Джона Вілліса Джина Кім Джез Хамбла.

Мета створення цієї книги — показати, як здійснити DevOps-трансформації, частиною яких були ми самі або їх спостерігали, а також розвіяти купу міфів стосовно того, чому DevOps не працюватиме в тих чи інших ситуаціях. Гадаемо, варто навести деякі з найбільш поширених міфів про DevOps, що нам доводилося чути. 

Міф: DevOps придатний лише для стартапів. Методи DevOps вперше були застосовані компаніями-єдинорогами з інтернет-індустрії: Google, Amazon, Netflix та Etsy. Кожна із цих компаній у певні моменти своєї історії ризикувала випасти із бізнесу через проблеми, що зазвичай виникають у «робочих конячок» традиційних організацій: небезпечні релізи, що призводять компанію до катастрофічного провалу, невміння швидко здійснювати зміни продукту або сервісу, щоби перевершити конкурентів у новій області, проблеми з дотриманням нормативних вимог, нездатність масштабуватися, високий ступінь недовіри між розробкою та експлуатацією тощо.

Однак кожна зі згаданих організацій спромоглася трансформувати свою архітектуру, технічні методи, виробничу культуру і досягти видатних результатів завдяки DevOps. Як уїдливо зауважив відомий американський фахівець з інформаційної безпеки Бранден Вільямс: «Досить розмов про єдинорогів або робочих конячок у DevOps, нехай залишаться тільки чистокровні скакуни, а решта відправляються на миловарню». 

Міф: DevOps замінює собою Agile. Принципи і методи DevOps поєднуються з Agile, причому багато хто відзначає, що DevOps — логічне продовження Agile, започаткованого ще у 2001 році. Agile часто виявляється ефективним каталізатором DevOps, оскільки зосереджений на діяльність невеликих команд, що безперервно постачають користувачам код високої якості.

Багато практик DevOps виникають тоді, коли ми продовжуємо керувати нашою роботою за межами мети, яку можна визначити як  «код, потенційно придатний для релізу», наприкінці кожної ітерації, розширюючи її так, аби наш код завжди знаходився в готовому для розгортання стані, а розробники щодня синхронізували нові зміни з основною гілкою коду й могли продемонструвати ці зміни у виробничих середовищах.

Міф: DevOps несумісний з ITIL. Багато хто розглядає DevOps як відповідь на ITIL або ITSM (IT Service Management), опис якого було вперше опублікований у 1989 році. ITIL відчутно вплинула на кілька поколінь практиків у галузі управління інфраструктурою, включаючи одного з авторів цієї книги. Це бібліотека методів, що постійно розвивається, призначена для кодифікації процесів і практик, що лежать в основі визнаних у всьому світі способів управління IT і охоплюють стратегію послуг, розробку і підтримку.

Методи DevOps можна зробити сумісними з процесами ITIL. Однак для забезпечення більш короткого циклу розробки і підвищення частоти розгортання, запропонованих DevOps, багато галузей процесів ITIL потребують тотальної автоматизації, що допоможе вирішити проблеми, пов’язані з процесами управління конфігураціями і релізами (наприклад, як забезпечити постійну готовність бази управління і бібліотеки програм). Оскільки ж DevOps вимагає, щоби помилки, що виникають, швидко виявлялися й усувалися, дисципліна застосування ITIL у проєктуванні архітектури, обробці збоїв, вирішенні проблем залишається актуальною як ніколи. 

Міф: DevOps несумісний з вимогами інформаційної безпеки. Відсутність традиційних методів контролю (таких, як поділ відповідальності, зміна процесів перевірки коду, перевірка безпеки вручну після завершення проєкту) може викликати тривогу у фахівців із безпеки. Однак це не означає, що в організаціях, які використовують DevOps, відсутній ефективний контроль. Замість робіт із забезпечення безпеки і перевірки відповідності вимогам інформаційної безпеки, що здійснюється на завершальному етапі проєкту, необхідні перевірки, інтегровані в кожну стадію щоденного циклу протягом усього циклу розробки. Зрештою це забезпечує більш високий ступінь якості та безпеки.

Міф: DevOps означає відсутність необхідності управління IT-експлуатацією, тобто NoOps (буквально: «ні експлуатації»). Чимало людей хибно трактують DevOps як цілковиту відмову від необхідності IT-експлуатації. Однак подібне трапляється не часто. Хоча характер виконання IT-операцій може змінитися, управління залишається важливим як ніколи. Просто на більш ранніх етапах життєвого циклу програмного забезпечення воно взаємодіє з розробкою, що продовжує діяти паралельно з IT-експлуатацією ще довго після того, як розроблений код буде розгорнутий у виробничому середовищі.

Замість того щоби відділ експлуатації розгрібав заявки, що надходять, вручну, DevOps дає розробникам можливість робити більшість операцій через API і платформи самообслуговування. Це стосується створення середовища, тестування і розгортання коду, отримання і відтворення метрик ПЗ тощо. Коли такий підхід реалізується, IT-експлуатація стає схожою на процес розробки (це так само справедливо для управління якістю і дотримання інформаційної безпеки), зчеплений з розробкою продукту, де під продуктом розуміється платформа, що використовується, аби надійно, швидко та безпечно тестувати IT-сервіси, розгортати їх і запускати у виробниче середовище. 

Міф: DevOps — це просто реалізація підходу «інфраструктура як код». Хоча багато практик і підходів DevOps, наведених у цій книзі, вимагають автоматизації, для реалізації DevOps також необхідна зміна архітектури системи і культури виробництва, що надає можливість досягати загальних цілей під час роботи з підвищення створюваної цінності IT. Це виходить далеко за рамки простої автоматизації. Як зазначав Крістофер Літл, технічний директор і один із найперших літописців DevOps: «DevOps — це не автоматизація, так само як астрономія — це не телескопи».

Міф: DevOps призначений лише для програм із відкритим вихідним кодом. Хоча багато випадків успішного впровадження DevOps дійсно мали місце в організаціях, які використовували ПЗ, що входило до групи LAMP (Linux, Apache, MySQL, PHP), проте мають місце успішні приклади, які не залежали від використаних технологій. Наприклад, у застосунках, написаних на Microsoft.NET, COBOL, мовою асемблера мейнфреймів, а також в системах SAP і навіть у коді вбудованих систем (як от вбудоване програмне забезпечення принтерів HP LaserJet).