DevOps простими словами: як IT-команді робити важливе і заробляти більше

Стаття написана у співавторстві з Андрієм Бауліним, Head of DevOps продуктової IT-компаніїMegogo .

Розбираємося, чому спроби «впровадження DevOps» не мають сенсу без конкретної мети і як оптимізувати роботу IT-компанії, коли мета є.

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

У технологічних стартапів з малою кількістю людей не програмуючий девопс — нонсенс. Навіщо він там? По суті, в таких командах ops — маленькі літери в кінці, а DEV — великі на початку. В стійких командах середнього розміру OPS набирають обертів, а девов і так багато, тому «питома вага» літер помітно змінюється.

Ми ніколи не ставили перед собою мету впровадити DevOps» або «найняти девопсов». Тому що — ну, хто це? Чому вони повинні зробити нас краще всіх? Чим вони відрізняються від тих людей-оркестрів, які в компанії і так було завжди? Ми створювали команду мотивованих операціоністів, які знають і поглиблюються в логіку продукту, працюють пліч-о-пліч з девелоперами і тестерами. І потім констатували, що багато в глобальному IT-співтовариство називають таких людей девопсами.

Навіщо нам DevOps

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

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

Нам не потрібні люди з титулом DevOps і умінням міркувати про Kubernetes 20 хвилин підряд, якщо вони не вміють пояснити, як TCP-пакет потрапляє з однієї ОС на іншу.

Ми продуктова компанія, і все у нас крутиться навколо продукту. У нас ніколи не було «системних адміністраторів», тому що не було таких систем, які мали б сенс і цінність без продукту. На початку 2010-х, коли ми виходили на ринок, в продуктових компаніях сисадмінами були люди, які чудово розуміють як бізнес-логіку своїх продуктів, так і складність їх масової постачання і обслуговування в продакшені. Такі ж люди зараз стають хорошими девопсами: розуміють, що, як і для чого робити.

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

Що (і хто) робить команду ефективної

Для початку ми описали людей, яких хочемо бачити в колективі: їх hard і soft skills, майндсет і роботу всієї команди. Ось ознаки, які вийшло виділити:

Структура має бути якомога плоскішою, ніяких начальників. Операціоністів не повинна хвилювати політика. Вони не повинні думати про те, «хто попросив це зробити», і оцінювати завдання, грунтуючись на ієрархії. Законно те, що логічно. «Більше прав» той, хто краще обґрунтовує.
Люди повинні бути самостійними. Співвідношення goal driven проти process oriented серед співробітників має бути максимально на користь перших, але для балансу потрібні і другі.
Вони повинні вміти костылять як боги! Але і вести рахунок «милиць», і правильно писати їх в технічний борг.
Cloud-навички для нас менш важливі, ніж on-premise. Людина, що вміє перетворити on-premise DC в пристойний private IAAS, в наших очах цінніше спритника в AWS-середовищі, наприклад.
Важливі хороші навички в темплейтизации, тяга до неї. От щоб хлібом не годуй, а дай побачити темплейт в розрізнених сутності і процесах.
«Автоматизація» і «аксіома» не повинні бути синонімами в голові операціоніста. Власне, повертаємося до третього пункту: вони повинні вміти костылять як боги!
Логіка важливіше наступності. На інтерв'ю в ігрових технічних завданнях ми намагаємося поставити людину в ситуацію, в якій він не може виїхати за рахунок енциклопедичних знань. І дивимося, як він думає в цих умовах, вміє пояснити хід своїх думок. До речі, дозволяємо брати на інтерв'ю телефон з інтернетом і гуглити.

Якими характеристиками повинен володіти IT operations

Продукт використовує користувач. І він повинен бути задоволений. У нас не в ходу фраза «ну нехай хто робив, той і розбереться». Наш operantions — «затичка» в будь-який біль, якої ще не знайдено конкретний господар.
Зручно — це прозоро і інтуїтивно. Чим менше треба пам'ятати і знати про сервіси і системах, тим краще. В ідеалі — нічого не треба пам'ятати і знати про сервісах. Але прозоро і інтуїтивно — не одно небезпечно (про це нижче).
Ми не плануємо на роки вперед, але все-таки плануємо. І ми не витрачаємо на планування істотні ресурси, економимо час.
Якщо хтось хоче спробувати новий продукт — він просто ставить собі завдання і встановлює PoC. Потім розповідає іншим.
Нові сутності в продакшені з'являються з двох причин:
а) це можна намалювати і укласти в описану схему: все повинно відповідати на питання «як створити ще сто таких, щоб було однакове і зручний»;
б) тому що треба «ось прям щас», треба ловити момент.
Менше нарад, більше ad hoc (тобто менше групових нарад, більше конкретних технічних діалогів і спорів).
По можливості, відсутність неінтерактивних комунікацій (зразок імейлів).
По можливості, присутність тикетной системи.
Чим раніше ops з'явиться серед dev під час реалізації чогось нового, тим краще. В ідеалі — встигнути з самого початку. Тому, замість роботи над єдиним пулом завдань, наші хлопці працюють кожен у своїх девелоперських командах.
У клієнт-саппорте эджайлу — ні. Якщо залишити телефонний саппорт з клієнтами наодинці, то ніякого покращення не буде. У цій області ITSM-підхід — наше все: поділ на рівні L1-L2-L3, по можливості — незалежний інцидент і проблем-менеджмент, робота зі статистикою інцидентів... Ми вкладаємо ресурси в це і все сильніше «закручуємо гайки». До речі, в Megogo з клієнт-саппортом тісно пов'язаний моніторинг і алертинг.
Безпека повинна бути прозорою. Вона не в приховуванні інформації, навпаки! І вона не повинна обтяжувати operantions. Це зовсім не означає, що безпекою можна знехтувати або порушувати принцип defense in depth. Це означає, що безпека — реалізовує її в якомусь випадку dev, DevOps або SecOps, — не повинна ламати дизайн, процеси та процедури в ім'я себе самої.

Напевно, кожен айтішник, працював у корпоративному секторі, стикався з ситуацією, коли безпечники замикаються самі на себе і стають самодостатньою структурою. Вони виробляють правила, сенсу яких вже не можуть чітко і ясно пояснити, як і довести їх ефективність статистикою. В цьому сенсі нам близький підхід PCI DSS, а також їх основний постулат: перш ніж захищати, звузьте скоуп.

В якому середовищі люди працюють ефективно

Якими характеристиками повинні володіти середовища, щоб описані вище люди, що працюють в описаному вище стилі, могли їх ефективно адмініструвати і розробляти?

Infrastructure as a code.
В рамках розумного — горизонтальне масштабування і динамічне все: каталог сервісів, service mesh і т. д.
Менше веб-морд, ще менше! Консолідуємо.
Якщо під час дизайну в графі «сценарій відновлення» стоїть вибір між «перезаснувати» або «з бекапа», то потрібно вибирати перше. Однозначно.
Прозорі структури можна документувати менш докладно, а то й зовсім не документувати, досить скетчів (тому у нас сильно лають за відступи від неймінг-конвенцій і тому подібні «дрібниці»).

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

DevOps-інструменти — це абстракція

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

Наприклад, в інтернет-статтях у переліку DevOps-інструментів часто згадується Jenkins. Так, Jenkins з'явився вже в часи DevOps. Але раніше його спокійно собі налаштовували старі добрі сисадміни.

В інтернеті повно статей на тему «у компанії використовують Y». Але вас не повинно цікавити той факт, що такий-то бізнес використовує Prometheus, Grafana або щось ще. Вам повинно бути цікаво, наскільки дана компанія схожа на вашу, які завдання вирішує і чому саме цими рішеннями. Потрібно дивитися, з чого вибирали довго використовують, ніж ще з подібних продуктів користуються, наскільки глибоко впровадження. Може, вже збираються відмовлятися від цього інструменту. Загалом, вам потрібні дрібниці. А назви самих продуктів не потрібні. Сформулюйте конкретну проблему і шукайте, які інструменти її вирішують.

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

Які висновки можна зробити з усього цього

Ніякої «інструкції» по впровадженню DevOps не існує. Більш того, вона не має сенсу. Немає єдиної системи, за якою потрібно організовувати DevOps в компанії. У нас, наприклад, є «девопсы девопсов» — якась core-команда, яка розробляє загальні для всіх команд речі. Але в цілому це віртуальна структура: системні завдання і субпроекти кочують від людини до людини. Немає окремо техсаппорта і девопсов. У Megogo девопсы не втратили ITIL-класифікації сисадмінів, як L3 техсаппорта.

Є якийсь поділ на ентерпрайз і продакшен, але обидві метасреды підтримують одні і ті ж люди. Тому наше завдання — робити ентерпрайз як можна більш гнучким і ненапряжным: ми намагаємося не плодити непотрібні сервіси, щоб їх не потрібно було підтримувати. І у нас виходить.

Ще раз: немає ніякого «покрокового плану впровадження DevOps». Але якщо все-таки спробувати сформулювати загальні поради, то їх всього два:

Не бійтеся переробляти. Дуже велика помилка — робити переформатування роботи у всьому і завжди. Бо перероблення — це, по суті, є життя.
Тверезо оцінюйте ціну помилок. Часто зробити помилку дешевше, ніж не допустити її.

Опубліковано: 15/05/19 @ 10:00
Розділ Різне

SEO Блог