Визначення DevOps дуже складне, тому щоразу доводиться запускати дискусію про це заново. Тільки на Хабрі тисяча публікацій на цю тему. Але якщо ви це читаєте, то, напевно, знаєте, що таке DevOps. Тому що я – ні. Привіт мене звати Олександр Тітов (@), і ми просто поговоримо про DevOps і я поділюся своїм досвідом.
Довго думав, як зробити моє оповідання корисним, тому тут буде багато питань — тих, які я сам собі задаю, і тих, які я ставлю клієнтам нашої компанії. Відповідаючи на ці питання, розуміння стає кращим. Я розповім навіщо потрібний DevOps на мій погляд, що це таке, знову ж таки, з моєї позиції, і як зрозуміти, що ви рухаєтеся до DevOps знову на мій погляд. Останній пункт буде через запитання. Відповідаючи на них самому собі, ви зможете зрозуміти, чи рухається ваша компанія до DevOps, чи в чомусь є проблеми.
У свій час я гуляв хвилями злиття і поглинання. Спочатку я попрацював у маленькому стартапі Qik, потім його купила трохи більша компанія Skype, яку потім купила ще трохи більша компанія Microsoft. У цей момент мені стало доступне бачення, як трансформується уявлення про DevOps у різних за величиною компаніях. Після цього мені стало цікаво вже з погляду ринку дивитися на DevOps, і ми з колегами організували компанію Експрес 42. Вже 6 років ми рухаємось на ній хвилями ринку.
Окрім іншого я один з організаторів спільноти DevOps Moscow та організатор DevOps -Days 2017, але 2018 я не організовував. Експрес 42 працює з багатьма компаніями. Ми пророщуємо там DevOps, дивимося, як це відбувається, робимо висновки, аналізуємо, розповідаємо свої висновки всім, навчаємо людей DevOps-практикам. Загалом, всіляко вирощуємо в цьому сенсі досвід та експертизу.
Навіщо DevOps
Перше питання, яке переслідує всіх і завжди – навіщо? Багато хто вважає, що DevOps – це просто автоматизація чи схожа штука, яка вже була у кожній компанії.
— У нас був Continuous Integration — це означає, що вже був DevOps, і навіщо все це бадилля потрібне? Там за кордоном розважаються, а нам працювати заважають!
За 9 років розвитку спільноти та методології вже стало зрозуміло, що це все ж таки не маркетингові блискітки, але все одно не до кінця зрозуміло навіщо він потрібен. Як у будь-якого інструменту та процесу, у DevOps є конкретні цілі, які він у результаті вирішує.
Все це пов'язано з тим, що світ змінюється. Він уникає підходу enterprise, коли компанії рухаються відразу до мрії, як співав наш пітерський класик, з точки А в точку В за певною стратегією, з побудованою для цього певною структурою.
В принципі, в IT все і має бути побудовано під цей підхід. Тут ІТ використовується виключно для автоматизації процесів.
Автоматизація не часто змінюється, бо коли компанія котиться наїждженою колією — що там міняти? Працює – не чіпай. Зараз у світі підходи змінюються, і той, що називається словом Agile, говорить про те, що кінцевої точки відразу не видно.
Коли компанія йде по ринку, працює з клієнтом — вона постійно досліджує ринок і змінює кінцеву точку В. Причому чим частіше компанія змінює свій напрямок, тим більше вона успішна, тому що вибирає більше ринкових ніш.
Стратегію демонструє цікава компанія, про яку я нещодавно дізнався. One Box Shave — сервіс з доставки бритв і приладдя для гоління з підписки в коробці. Вони можуть кастомізувати свою «коробочку» під різних клієнтів. Цим займається певний софт, який потім відправляє замовлення корейську фабрику, що випускає товар.
Цей продукт купила компанія Unilever за 1 млрд доларів. Наразі він конкурує з Gillette і від'їв у нього значну частку споживачів на американському ринку. One Box Shave кажуть:
- 4 леза? Ви серйозно? Навіщо вам це треба - це не покращує якість гоління. Спеціально підібраний крем, віддушка та якісна бритва з двома лезами вирішують набагато більше питань, ніж ці безглузді 4 леза Gillette! То скоро до 10 дійдемо?
Так світ змінюється. Unilever заявляють про те, що вони мають круту IT-систему, яка дозволяє це робити. У результаті це виглядає як концепція Час виходу на ринок, Про яку вже хтось тільки не говорив.
Сенс Time-to-market не в тому, як часто ми деплоїмося. Часто можна деплоїти, але при цьому релізні цикли будуть довгими. Якщо тримісячні релізні цикли накладати один на одного, зрушуючи на тиждень, виходить, що компанія ніби деплоїться раз на тиждень. А від ідеї до кінцевої реалізації триває 3 місяці.
Time-to-market - це про мінімізацію часу від ідеї до кінцевої реалізації.
І тут із ринком взаємодіє ПЗ. Так у One Box Shave із клієнтом взаємодіє сайт. У них немає продавців – просто сайт, де відвідувач кликає та залишає побажання. Відповідно, на сайті треба постійно розміщувати щось нове, оновлювати його відповідно до побажань. Наприклад, у Південній Кореї голяться не так, як у Росії, і їм подобається у ароматі не запах сосни, а, наприклад, моркви ванілі.
Оскільки потрібно швидко змінювати наповнення сайту, розробка програмного забезпечення сильно змінюється. Через ПЗ ми повинні дізнаватись, що хоче клієнт. Раніше ми це дізнавалися якимись обхідними шляхами, наприклад, через бізнес-менеджмент. Потім проектували, закладали вимоги до IT-системи, і все було круто. Зараз по-іншому — програмне забезпечення проектується всіма, хто включений у процес, у тому числі й інженерами, тому що вони дізнаються через технічні характеристики, як працює ринок, і теж діляться з бізнесом своїми інсайтами.
Наприклад, у компанії Qik ми раптово дізналися, що людям дуже подобається завантажувати контакт-листи на сервер, і вони поклали нам програму. Спочатку ми про це не замислювалися. У класичній компанії все б вирішили, що це бага, тому що в спеку не написано, що це має класно працювати і взагалі було реалізовано на коліні, вимкнули б фічу і сказали: «Це нікому не потрібно, найголовніше, що основна функціональність працює» . А технологічна компанія в цьому бачить можливість і починає змінювати софт згідно з цим.
У 1968 році прозорливий хлопець Мелвін Конвей сформулював таку ідею.
Організація, що створює систему, обмежена дизайном, що копіює структуру комунікації у цій організації.
Якщо докладніше, щоб виробляти системи іншого типу, треба ще й мати комунікаційну структуру всередині компанії іншого типу. Якщо у вас комунікаційна структура верхньо-ієрархічна, то це не дозволить вам робити системи, які можуть забезпечувати дуже високий показник Time-to-market.
Почитати можна . Він важливий для розуміння культури або філософії DevOps, оскільки єдине, що базово змінюється у DevOps — це саме структура комунікації між командами.
З погляду процесу, до DevOps всі стадії: аналітика, розробка, тестування, експлуатація проходили лінійно.
У випадку DevOps усі ці процеси відбуваються одночасно.
Time-to-market тільки так і може виконуватись. Для людей, які працювали в старому процесі, це виглядає дещо космічно і взагалі так собі.
То навіщо потрібний DevOps?
Для розробки цифрових продуктів. Якщо у компанії немає цифрового продукту, DevOps не потрібен — це дуже важливо.
DevOps долає швидкісні обмеження послідовної схеми виробництва ПЗ. У ньому всі процеси відбуваються одночасно.
Збільшується складність. Коли DevOps-євангелісти розповідають, що з ним вам стане простіше випускати програмне забезпечення – це маячня.
З DevOps все буде лише складніше.
На конференції на стенді Авіта можна було подивитися, що таке задеплоїти Docker-контейнер - нереальне завдання. Складність стає надмірною, треба жонглювати багатьма кульками одночасно.
DevOps повністю змінює процес та організацію в компанії - Точніше, змінює не DevOps, а цифровий продукт. Щоб прийти до DevOps, треба все-таки цей процес повністю змінити.
Запитання для фахівця
А що ви? Питання, які ви можете собі поставити, працюючи в компанії та розвиваючись як фахівець.
Чи є у вас стратегія створення цифрового продукту? Якщо є вже добре. Це означає, що ваша компанія рухається у бік DevOps.
Ваша компанія вже створює цифровий продукт? Це означає, що ви можете піднятися на щабель вище, займатися справами цікавіше — з точки зору DevOps знову-таки. Я тільки з цього погляду говорю.
Ваша компанія є одним з лідерів ринку в ніші з цифровим продуктом? Spotify, Яндекс, Uber - компанії, які знаходяться на піку технологічного прогресу зараз.
Поставте собі ці питання, і якщо всі відповіді негативні, то, можливо, вам і не варто займатися DevOps у цій компанії. Якщо ж вам тема DevOps реально цікава, можливо, вам варто перейти в іншу компанію? Якщо ваша компанія хоче піти в DevOps, але на всі запитання ви відповіли «Ні», вона нагадує цього прекрасного носорожика, який ніколи не зміниться.
Організація
Як я вже сказав, за законом Конвею у компанії змінюється організація. Почну з того, що заважає DevOps проникати всередину компанії саме з точки зору організації.
Проблема «колодязь»
Англійське слово «Silo» перекладено тут російською як «колодязь». Сенс цієї проблеми в тому, що між командами немає обміну інформацією. Кожна команда копає свою експертизу вглиб, при цьому не будуючи загальної карти, в якій можна орієнтуватися.
Чимось це нагадує людину, яка тільки приїхала до Москви і ще не вміє орієнтуватися картою метро. Москвичі зазвичай чудово знають свій район, а по всій Москві орієнтуються картою метро. Коли ти приїжджаєш до Москви вперше, немає цієї навички, і ти просто дезорієнтований.
DevOps пропонує пройти цей момент дезорієнтації та всім підрозділам разом побудувати спільну карту взаємодії.
Цьому заважають два чинники.
Наслідок корпоративної системи управління. Вона збудована окремими ієрархічними «колодцями». Наприклад, є певні KPI у компаніях, які цю систему підтримують. З іншого боку, заважають мізки людини, якій складно вийти за межі своєї експертизи та орієнтуватися у всій системі. Це просто некомфортно. Уявіть собі, що ви потрапили до аеропорту Бангкока - там швидко не зорієнтуєшся. У DevOps теж складно орієнтуватися, і тому люди кажуть, що треба знайти провідника, щоб туди потрапити.
Але найголовніше, що проблема «колодязь» для інженера, який перейнявся духом DevOps, начитався Фаулера і купу інших книжок, виявляється у тому, що «криниці» не дозволяють робити «очевидні» речі. Ми часто збираємось після DevOps Moscow, розмовляємо один з одним, і люди скаржаться:
— Ми хотіли просто CI запустити, а вийшло, що це не треба менеджменту.
Це відбувається саме через те, що CI и Continuous Delivery process перебувають на кордоні багатьох експертиз. Просто не подолавши проблему «колодязь» на організаційному рівні, не вийде просунутися далі, щоб ви не робили і як би це сумно не було.
Кожен учасник процесу в компанії: розробники бекенду та фронтенду, тестування, DBA, експлуатація, мережа, копає у свій бік, а загальної карти не має ніхто, крім управлінця, який якось їх оглядає та керує методом «розділяй та володарюй».
Люди борються за якісь зірочки чи прапорці, кожен копає свою експертизу.
У результаті, коли постає завдання все це з'єднати разом і побудувати спільний пайплайн, і за зірочки і прапорці вже боротися не треба, постає питання — а що робити взагалі? Треба якось домовлятись, а як це робити, нас у школі ніхто не вчив. Ми ще зі школи навчені: восьмий клас — ого! - Порівняно з сьомим класом! Тут те саме.
У вашій компанії так само?
Щоб це перевірити, можна поставити такі питання.
Чи використовуються команди загальними інструментами, чи роблять внесок у зміни цих спільних інструментів?
Наскільки часто команди переформуються — одні спеціалісти з однієї команди переходять до іншої команди? Саме в DevOps-середовищі це стає нормальним, тому що іноді людина просто не може зрозуміти, чим займається інша зона експертизи. Він переходить в інший відділ, два тижні там працює, щоб створити собі карту орієнтації та взаємодії з цим відділом.
Чи можна створити комітет зі зміни та щось змінити? Чи для цього потрібна сильна рука найвищого керівництва та розпорядження? Нещодавно я написав у Facebook як один маловідомий банк через розпорядження впроваджує інструменти: написали розпорядження, рік впроваджуємо, дивимося, що відбувається. Це, звичайно, довго та сумно.
Наскільки важливо для менеджерів здобувати особисті досягнення без урахування досягнень компанії?
Якщо ви відповісте на ці питання, стане зрозуміліше, чи є у вас така проблема в компанії.
Інфраструктура як код
Після того, як цю проблему пройдено, перша важлива практика, без якої складно просунутися в DevOps далі — це інфраструктура як код.
Найчастіше інфраструктуру як код сприймають так:
- Давайте все автоматизуємо на bash, обмажемо скриптами, щоб у адмінок було менше ручної роботи!
Але це не так.
Інфраструктура як код має на увазі, що IT-систему, з якою працюєте, ви описуєте у вигляді коду, щоб постійно розуміти її стан.
Спільно з іншими командами ви створюєте карту у вигляді коду, яка всім зрозуміла, якою можна орієнтуватися, навігувати. Без різниці, на чому це зроблено - Chef, Ansible, Salt, або використовуються YAML-файли в Kubernetes - немає різниці.
На конференції колега із 2ГІС розповідав, як вони зробили свою внутрішню штуку для Kubernetes, яка описує пристрій окремих систем. Щоб описати 500 систем, їм потрібен окремий інструмент, який цей опис генерує. Коли є цей опис, кожен може звірятися один з одним, моніторити зміни, як його змінити та покращити, чого не вистачає.
Погодьтеся, окремі bash-скрипти зазвичай не дають цього розуміння. В одній із компаній, де я працював, була навіть назва write only-скрипт — коли скрипт написаний, а прочитати його вже неможливо. Думаю, це вам теж знайоме.
Інфраструктура як код – це код, який описує актуальний стан інфраструктури. Над цим кодом спільно працює безліч продуктових, інфраструктурних та сервісних команд, і, найголовніше, всі вони повинні розуміти, як цей код взагалі працює.
Код супроводжується згідно з кращими практиками роботи з кодом: спільна розробка, код-ревью, XP-programming, тестування, пулреквести, CI для інфраструктур коду - це все придатно і можна використовувати.
Код стає спільною мовою всім інженерів.
Зміна інфраструктури в коді не займає багато часу. Так, в інфраструктурному коді також може бути технічний борг. Зазвичай команди стикаються з ним через півтора року після того, як почали впроваджувати «інфраструктуру як код» у вигляді купи скриптів або навіть Ansible, який вони пишуть як спагетті-код, і ще bash-скрипти туди підкидають у топочку!
Важливо: якщо ви ще не спробували цю погань, запам'ятайте, що Ansible - не bash! Уважно читайте документацію, вивчайте, що про це взагалі пишуть.
Інфраструктура як код – це розділення інфраструктурного коду на окремі шари.
Ми у себе в компанії виділяємо 3 базові шари, які дуже зрозумілі і прості, але їх може бути більше. Ви можете подивитися на ваш інфраструктурний код і сказати, чи є у вас ця умова чи ні. Якщо ніякі шари не виділяються, треба виділити час і порефакторить трошки.
Базовий шар — це як налаштовується ОС, бекапи та інші низькорівневі штуки, наприклад, як Kubernetes розгортається на базовому рівні.
Рівень сервісів - Це ті сервіси, які ви даєте розробнику: логування як сервіс, моніторинг як сервіс, база даних як сервіс, балансувальник як сервіс, черга як сервіс, Continuous Delivery як сервіс - купа сервісів, які окремі команди можуть надавати розробці. Все це необхідно описувати окремими модулями у вашій системі керування конфігурацією.
Шар, де робляться додатки і описується, як вони розгортатимуться поверх двох попередніх шарів.
Контрольні питання
Чи є у вас у компанії загальний інфраструктурний репозиторій? Чи контролюєте ви технічний обов'язок в інфраструктурі? Ви використовуєте практики розробки в інфраструктурному репозиторії? Чи нарізано вашу інфраструктуру на шари? Можна звіритися зі схемою Base-Service-APP. Наскільки складно зробити зміну?
Якщо ви стикалися з тим, що внесення змін займало півтора дні, то це означає, що у вас з'явився технічний борг і з ним треба попрацювати. Ви натрапили на граблі технічного боргу в інфраструктурному коді. Я пам'ятаю багато таких історій, коли щоб поміняти якийсь CCTL, треба переписати половину інфраструктурного коду, тому що творчість і бажання все автоматизувати призвело до того, що скрізь усе закоркувано, всі ручки прибрано, і потрібно рефакторити.
Безперервне постачання
Підіб'ємо дебіт із кредитом. Спочатку з'являється опис інфраструктури, який може бути досить базовим. Необов'язково все описувати детально, але якийсь базовий опис потрібний, щоб ви могли з цим працювати. Інакше незрозуміло, поверх чого далі взагалі робити безперервне постачання. Всі ці практики розгортаються одночасно, коли ви приходите до DevOps, але треба починати з розуміння того, що у вас є, і як цим керувати. Це якраз практика інфраструктури як код.
Після того, як стало зрозуміло, що у вас є, як цим керувати, ви починаєте вигадувати, як код розробника максимально швидко відправити на продакшн. Я маю на увазі разом із розробником — пам'ятаємо про проблему «колодязь», тобто не окремі люди це вигадують, а командою.
Коли ми з Ванею Євтуховичем побачили першу книжку Джеза Хамбла та групи авторів "Continuous Delivery", яка вийшла у 2009 році, то довго думали, як перекласти її назву російською мовою. Хотіли перекласти як «Постійно доставляти», але, на жаль, переклали як «Безперервне постачання». Мені здається, що в нашій назві є щось таке російське з напором.
Постійно доставляти це означає
Код, який лежить у продуктовому репозиторії, завжди може бути викачений у продакшн. Він може бути і не викачаний, але завжди готовий до цього. Відповідно, ви завжди пишіть код з важко зрозумілим почуттям деякого занепокоєння під куприком. Воно часто з'являється, коли викочуєш інфраструктурний код. Це почуття деякого занепокоєння і має бути присутнім - воно викликає мозкові процеси, які дозволяють писати код трохи по-іншому. Це має бути зафіксовано у правилах усередині розробки.
Щоб постійно доставляти, потрібен формат артефакту, що проходить інфраструктурною платформою. Якщо ви кидаєте інфраструктурною платформою різного формату «відходи життєдіяльності», то вона у вас стає не уніфікованою, її складно супроводжувати, виникає проблема технічного боргу. Формат артефакту необхідно вирівняти - це теж колективне завдання: треба всім разом зібратися, пошелестіти мізками і придумати цей формат.
Артефакт безперервно покращується і змінюється під продакшн-середовище під час проходження по пайплайну постачання. Коли артефакт рухається пайплайном, він весь час стикається з якимись незручними для нього речами, які схожі на те, з чим стикається артефакт, який ви викладаєте в продакшн. Якщо в класичній розробці цим займається сисадмін, який робить викочування, то в DevOps-процесі це відбувається постійно: тут його якимись тестами покрутили, тут - в Kubernetes-кластер закинули, який більш-менш схожий на продакшн, тут раптово запустили тестування навантаження. .
Це чимось нагадує гру Пакман – артефакт проходить якусь історію. При цьому важливо контролювати, чи реально код проходить історію і вона якось пов'язана з вашим продакшном. Історії з продакшенів можна затягувати всередину Continuous Delivery процесу: було так, коли щось впало, тепер давайте цей сценарій просто запрограмуємо всередину системи. Щоразу код буде проходити цей сценарій теж, і ви не зіткнетеся наступного разу з цією проблемою. Ви дізнаєтеся про неї раніше, ніж вона вийде до вашого клієнта.
Різні стратегії деплоїв. Наприклад, ви використовуєте AB-тестування або канаркові деплойменти, щоб по-різному «мацати» код на різних клієнтах, отримувати інформацію про те, як код працює, і раніше, ніж коли він викотиться на 100 млн користувачів.
"Постійно доставляти" виглядає так.
Процес поставки Dev, CI, Test, PreProd, Prod - це не окреме оточення, це стейджі або станції з вогнетривкими сумами, за якими проходить ваш артефакт.
Якщо у вас є інфраструктурний код, описаний як Base Service APP, то він допомагає не забути всі сценарії, і записати їх теж у вигляді коду для цього артефакту, просувати артефакт та міняти його по ходу руху.
Запитання для самоперевірки
Час від опису фічі до викочування в продакшен у 95% випадків менше тижня? Чи підвищується якість артефакту кожному етапі пайплайна? Чи є історія, якою він проходить? Ви використовуєте різні стратегії деплою?
Якщо всі відповіді так, то ви нереально круті! Напишіть відповіді у коментарі — я буду радий).
Зворотній зв'язок
Ця найскладніша практика із усіх. На конференції DevOpsConf колега з Infobip, розповідаючи про неї, трохи плутався у словах, бо це справді дуже складна практика про те, що треба моніторити взагалі все!
Наприклад, давно, коли я працював у Qik і ми зрозуміли, що треба моніторити взагалі все. Ми це зробили, і у нас в Zabbix з'явилося 150 000 items, які постійно моніторяться. Це було страшно, технічний директор крутив пальцем біля скроні:
— Хлопці, ви навіщо сервак гвалтуєте чимось?
Але потім стався випадок, який показав, що це дуже крута стратегія.
Постійно почав падати один із сервісів. Спочатку він не падав, що цікаво, туди код не дописувався, тому що це був базовий брокер, у якому практично не було бізнес-функціональності, він просто ганяв повідомлення між окремими сервісами. Сервіс не змінювався 4 місяці, і раптом почав падати з помилкою "Segmentation fault".
Ми були в шоці, відкрили наші графіки в Zabbix, і з'ясувалося, що виявляється, півтора тижні тому сильно змінилася поведінка запитів в API-сервісі, який використовує цей брокер. Далі ми подивилися, що змінилася частота посилки певного типу повідомлень. Після того з'ясували, що це android-клієнти. Ми запитали:
— Хлопці, а що у вас трапилося півтора тижні тому?
У відповідь почули цікаву історію, що вони переробили UI. Навряд чи хтось одразу скаже, що змінив HTTP-бібліотеку. Для android-клієнтів це як мило змінити у ванній – вони просто це не пам'ятають. У результаті, після 40 хвилин розмови, ми з'ясували, що вони змінили HTTP-бібліотеку, і в неї змінилися дефолтні таймінги. Це призвело до того, що змінилася поведінка трафіку на сервері API, що і призвело до ситуації, яка викликала гонку всередині брокера, і він почав падати.
Без глибокого моніторингу це розкрити взагалі неможливо. Якщо ж в організації ще є проблема «колодязь», коли кожен перекидає один на одного, це може жити роками. Ви просто рестартуєте сервер, тому що неможливо вирішити проблему. Коли ви моніторите, відстежуєте, трекаєте всі події, які у вас є, і використовуєте моніторинг як тестування - пишете код і відразу ж вказуєте, як його промоніторити, також у вигляді коду (у нас вже інфраструктура як код є), все стає зрозумілим як на долоні. Навіть такі складні проблеми легко відстежуються.
Збирайте всю інформацію про те, що відбувається з артефактом на кожній стадії процесу постачання - не продакшн.
Моніторинг вантажте на CI, і там вже буде видно якісь базові речі. Далі ви їх побачите і в Test, і в PredProd, і в тестуванні навантаження. Збирайте інформацію на всіх стадіях, причому не лише метрики, статистику, а й логи: як викотився додаток, аномалії — збирайте все.
В іншому випадку буде складно розібратися. Я вже казав, що DevOps – це велика складність. Щоб упоратися з цією складністю, потрібно мати нормальну аналітику.
Запитання для самоконтролю
Ваш моніторинг та логування – це засіб розробки для вас? Ваші розробники, і ви навіть коли пишуть код, думають про те, як його замоніторити?
Чи дізнаєтесь ви про проблеми від клієнтів? Чи ви розумієте клієнта краще з моніторингу та логування? Чи розумієте ви систему краще з моніторингу та логування? Чи змінюєте ви систему просто тому, що побачили, що тренд у системі зростає і розумієте, що ще 3 тижні і все загнеться?
Коли ви маєте ці три компоненти, ви можете подумати про те, яка у вас в компанії інфраструктурна платформа.
Інфраструктурна платформа
Сенс не в тому, що це набір розрізнених інструментів, що є в кожній компанії.
Сенс інфраструктурної платформи в тому, що всі команди користуються цими інструментами та розвивають їх спільно.
Зрозуміло, що є окремі команди, які відповідають за розвиток окремих шматків інфраструктурної платформи. Але відповідальність за розвиток, працездатність, просування інфраструктурної платформи несе кожен інженер. На внутрішньому рівні це стає загальним інструментом.
Всі команди розвивають інфраструктурну платформу, дбайливо ставляться до неї як до власного IDE. У своєму IDE ви ставите різні плагіни, щоб все було красиво та швидко, настроюєте гарячі клавіші. Коли ви відкриваєте Sublime, Atom або Visual Studio Code, у вас там сипляться помилки коду і ви розумієте, що взагалі неможливо працювати, вам відразу стає сумно і ви біжите лагодити свій IDE.
Так само ставтеся до вашої інфраструктурної платформи. Якщо ви розумієте, що з нею щось не те, залишайте заявку, якщо не можете відремонтувати самі. Якщо там щось просте — правте самостійно, відправляйте pull request — хлопці розглядають, додають. Це дещо інший підхід до інженерного інструментарію у голові розробника.
Інфраструктурна платформа забезпечує перенесення артефакту від розробки клієнту із постійним підвищенням якості.. В ІП запрограмовано набір історій, що трапляються з кодом продакшн. За роки розробки цих історій стає дуже багато, частина з них унікальна і стосується тільки вас — їх неможливо нагуглити.
У цей момент інфраструктурна платформа стає вашою конкурентною перевагоютому що в неї зашито те, чого немає в інструменті конкурента. Чим глибша ваша ІП, тим більша ваша конкурентна перевага в сенсі Time-to-market. Тут з'являється проблема vendor lock: ви можете взяти собі чужу платформу, але використовуючи чужий досвід, ви не будете розуміти, наскільки він релевантний до вас Так, не всяка компанія може збудувати платформу типу Амазона. Це складна грань, де досвід компанії релевантний її становищу на ринку, і спускати туди vendor lock не можна. Про це також важливо подумати.
Схема
Це базова схема інфраструктурної платформи, яка допоможе вам налагодити усі практики та процеси в DevOps-компанії.
Розглянемо, із чого вона складається.
Система оркестрації ресурсів, яка надає CPU, пам'ять, диск додатків та інших сервісів. Поверх цього — сервіси низького рівня: моніторинг, логування, CI/CD Engine, сховище артефактів, інфраструктура як код системи.
Сервіси вищого рівня: база даних, як сервіс, черги як сервіс, Load Balance як сервіс, resizing малюнків як сервіс, Big Data фабрика як сервіс. Поверх цього — пайплайн, який постачає постійно модифікований код вашому клієнту.
Ви отримуєте інформацію про те, як ваше програмне забезпечення працює у клієнта, змінюєте, знову поставляєте цей код, отримуєте інформацію — і так постійно розвиваєте і інфраструктурну платформу, і ваше програмне забезпечення.
На схемі delivery pipeline складається з багатьох стейджів. Але це принципова схема, наведена для прикладу — не треба повторювати її один в один. Стейджі взаємодіють із сервісами, як із сервісами — кожна цеглина платформи несе свою історію: як виділяються ресурси, як додаток запускається, працює з ресурсами, моніториться, змінюється.
Важливо розуміти, що кожна частина платформи несе історію, і запитувати себе - яку історію несе ця цегла, можливо, її варто викинути і замінити стороннім сервісом. Наприклад, чи можна замість цегли поставити Okmeter? Можливо, хлопці вже прокачали цю експертизу набагато більше, ніж ми. Але може й ні — можливо, ми маємо унікальну експертизу, нам треба поставити Prometheus і розвивати це далі.
Створення платформи
Це складний комунікаційний процес. Коли у вас є базові практики, ви запускаєте спілкування між різними інженерами та фахівцями, які виробляють вимоги та стандарти, та постійно їх змінюють до різних інструментів та підходів. Тут важлива культура, яка є у DevOps.
З культурою все дуже просто. це співробітництво та комунікаціятобто бажання працювати в загальному полі один з одним, бажання володіти одним інструментом разом. Тут немає ніякого rocket science – все дуже просто, банально. Наприклад, ми всі живемо у під'їзді та підтримуємо його чистоту — такий рівень культури.
А що ви?
Знову питання, які ви можете собі поставити.
Чи виділено інфраструктурну платформу? Хто відповідає за її розвиток? Чи ви розумієте конкурентні переваги своєї інфраструктурної платформи?
Ці питання треба постійно собі ставити. Якщо щось можна винести на сторонні послуги - потрібно виносити, якщо сторонній сервіс починає блокувати ваш рух, то треба будувати систему в собі.
Отже, DevOps…
… це складна система, у ньому мають бути:
- Цифровий продукт.
- Бізнес-модулі, які цей цифровий продукт розвивають.
- Продуктові команди, які пишуть код.
- Практики Continuous Delivery.
- Платформи як обслуговування.
- Інфраструктура як сервіс.
- Інфраструктура як код.
- Окремі практики підтримки надійності, зашиті всередині DevOps.
- Практика зворотний зв'язок, яка описує все це.
Можна використовувати цю схему, підфарбувавши в ній те, що вже у вас в компанії є в якомусь вигляді: це розвинулося чи ще треба розвинути.
Вже за кілька тижнів пройде . у складі РІТ++. Приходьте на конференцію, де на вас чекає багато крутих доповідей про безперервне постачання, інфраструктуру як код і DevOps-трансформацію. , останній дедлайн цін 20 травня
Джерело: habr.com