DevOps навпаки, або Як не треба робити

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

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

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

Я постараюся описати проблеми, які сам бачив і дати слушні поради, як їх вирішувати. Деякі проблеми не стосуються тільки напрямки DevOps.

Людина «bus factor»

«Василь знає цю систему краще за всіх, даймо йому це завдання!», «Василь найшвидше впорається!». Менеджери люблять надійних та обізнаних інженерів, які 100% дадуть результат. Але такими рішеннями ви точно отримаєте проблеми у майбутньому.

Оскільки інші члени команди поняття не мають, як працювати з цією системою і що робити у разі виникнення проблеми.

Як треба:

  1. Розподіл знань: замість покладатися лише на одну людину, команда повинна прагнути до розподілу знань і компетенцій за системою. Цього можна досягти шляхом навчання та обміну знаннями між членами команди. Важливо створити культуру знань, де кожен може розуміти та працювати з різними аспектами системи.
  2. Документація та шаблони: важливо створити докладну документацію про систему, її компоненти, налаштування та процеси. Це допоможе новим членам команди якнайшвидше освоїтися і дозволить їм розібратися в системі навіть без безпосередньої допомоги «експерта». Крім того, використання шаблонів та стандартів може спростити процес розгортання та керування системою.
  3. Регулярні ревізії коду: впровадження практики регулярних ревізій коду допоможе забезпечити те, що кілька членів команди знають та розуміють різні частини системи. Це також допоможе виявити потенційні проблеми та покращити якість коду.
  4. Навчання та розвиток команди: вкладення часу та ресурсів у навчання та розвиток членів команди є важливим аспектом успішної реалізації DevOps. Проведення тренінгів, семінарів та конференцій допомагає удосконалювати навички команди та розширювати їх знання.

Перейменовуємо Ops на DevOps, і все буде супер

Часто менеджери сподіваються, що перейменувавши команду, вони отримають необхідний ефект. Нічого подібного: цей «Карго культ» не працює, і не варто навіть витрачати на це час, ви можете називатися як завгодно, platform team, system team, DevOps team.

Головне, щоб інженери розуміли, який «value» вони несуть бізнесу, які bottleneck усувають та як допомагають побудувати потік цінності.

Як треба:

  1. Сфокусуватись на цінності: замість простого перейменування команди, необхідно зосередитись на розумінні цінності, яку команда DevOps може надати бізнесу. Визначте ясні цілі та очікування від команди та переконайтеся, що кожен член команди розуміє свою роль у досягненні цих цілей.
  2. Навчання та розвиток навичок: забезпечте команду можливістю отримувати навчання та розвивати свої навички в області DevOps. Це допоможе інженерам краще розуміти концепції та найкращі практики, пов’язані з DevOps, та застосовувати їх у своїй роботі.
  3. Крос-функціональність: важливо, щоб команда DevOps була крос-функціональною та включала фахівців з різними навичками та досвідом. Наявність різноманітних ролей (розробники, системні адміністратори, QA-інженери тощо) у команді дозволить ефективніше вирішувати завдання та реагувати на проблеми.
  4. Співпраця та комунікація: побудуйте культуру співробітництва та відкритої комунікації всередині команди та з іншими відділами. Регулярні зустрічі, обмін знаннями та досвідом допоможуть підвищити ефективність команди та усунути можливі бар’єри у співпраці.

«Ми всі працюємо не підводячи голови»

Команда перевантажена, вони всі працюють, навіть овертайм, і так постійно, пожежі-пожежі-пожежі, і всім завжди ніколи голову підняти.

Як треба:

  1. Розумний розподіл навантаження: важливо забезпечити баланс між обсягом роботи та можливостями команди. Розбийте завдання на дрібніші та пріоритезуйте їх відповідно до важливості і терміновості. Використовуйте методологію управління завданнями, такими як Agile або Kanban, щоб покращити планування та розподіл роботи.
  2. Автоматизація рутинних завдань: ідентифікуйте рутинні та повторювані завдання, які забирають багато часу, та автоматизуйте їх за допомогою інструментів та скриптів. Це допоможе знизити ручну роботу та звільнити час для стратегічних завдань.
  3. Регулярні ретроспективи: проводьте регулярні сесії ретроспективи, де команда може обговорити свою роботу, виявити проблеми.

«Я свій merge зроблю наприкінці тижня, заллю все, що напрацював протягом місяця»

Це стосується не лише девопс, а й розробників загалом. Великі зміни вимагають більше зусиль на код-рев’ю.

Як треба:

  1. Часті та маленькі мержі: рекомендується часто виконувати маленькі мержі замість величезних змін, які накопичуються протягом тривалого часу. Це дозволяє ефективніше керувати кодовою базою, виявляти та виправляти проблеми раніше та зменшувати ризик виникнення конфліктів при злитті коду.
  2. Код-рев’ю: приділіть належну увагу процесу код-рев’ю. Це дозволяє виявляти помилки, покращувати якість коду та обмінюватися знаннями в команді. Намагайтеся проводити код-рев’ю на ранніх етапах розробки та приділити достатньо часу на його виконання.
  3. Автоматичні тести: впровадження автоматичних тестів дозволяє виявляти проблеми та помилки у коді на ранніх стадіях. Це спрощує процес код-ревью і допомагає забезпечити стабільність системи.
  4. Постійне спілкування: Вважливо підтримувати постійну комунікацію між розробниками та іншими членами команди. Обговоріть зміни, плани та проблеми з колегами, щоб синхронізувати зусилля та уникнути конфліктів під час злиття коду.

Збираємо напрацьоване за місяць, і плануємо величезний реліз.

Реліз всього і вся «бажано» запланувати на п’ятницю. Природно, команда займається тільки деплоєм, команда працює у вихідні, є купа змін, які впливають одна на одну. У неділю ми вирішуємо відкотити все назад.

Як треба:

  1. Інкрементальні ітерації: рекомендується використовувати методологію розробки на основі інкрементів, таку як Agile або Scrum. Розділіть проєкт на дрібніші ітерації та плануйте досягнення конкретних цілей на кожній ітерації. Це дозволить керувати ризиками та краще контролювати якість змін.
  2. Поступові релізи: розробляйте функціональність і випускайте її поступово, а не відразу. Це дозволить контролювати вплив змін та швидко реагувати на можливі проблеми. Плануйте релізи на ранні етапи тижня, щоб ви мали достатньо часу для розв’язання проблем, якщо вони виникнуть.
  3. Контроль змін: керуйте змінами уважно та документуйте всі внесені зміни. Використовуйте систему контролю версій та відстежуйте всі зміни коду та інфраструктури. Це допоможе вам легко відстежити, що і коли було змінено, та швидко повернутися до попереднього робочого стану у разі потреби.
  4. Тестування та зворотний зв’язок: постійно тестуйте вашу систему та програму на кожному етапі розробки. Регулярно отримуйте зворотний зв’язок від користувачів та зацікавлених сторін. Це допоможе виявити проблеми та покращити якість продукту.
  5. Автоматизація та контейнеризація: використовуйте інструменти автоматизації розгортання та контейнеризації, такі як Docker та Kubernetes. Це дозволить вам швидко та надійно розгортати зміни та ізолювати їх від інших компонентів системи.
  6. Безперервна інтеграція та доставка: впровадьте процеси безперервної інтеграції (CI) та безперервної доставки (CD). Це дозволить вам автоматично тестувати, збирати та розгортати зміни при кожному коміті чи мержі. Це спрощує процес інтеграції змін та знижує ризик помилок.

«Ми терміново закриваємо цю проблему!»

«Наш важливий клієнт прийшов, і нам терміново треба викотити фікс! Яке тестування?!». Скільки разів ви чули це на роботі?:) Саме так, ми ламаємо всі процеси, щоб терміново викотити все в прод. До чого це призводить вже багато хто розуміє на власній шкурі.

Як треба:

  1. Тестування та зворотний зв’язок: не поступайтеся важливістю тестування, навіть при термінових завданнях. Дотримуйтесь процесу тестування та якісної перевірки перед викочуванням змін у продакшн-середовище. Терміновість не повинна превалювати над якістю та стабільністю системи.
  2. Регулярні релізи та автоматизація: прагніть регулярних релізів, щоб зменшити навантаження термінових змін. Автоматизуйте процеси складання, тестування та розгортання, щоб прискорити викочування змін у продакшн та знизити ризики.
  3. Комунікація та участь зацікавлених сторін: залучайте зацікавлені сторони до прийняття рішень на термінових завданнях. Поясніть їм ризики, пов’язані з недостатнім тестуванням і терміновими викочуваннями, та спільно прийміть обґрунтоване рішення.

«У мого друга Степана ось так працює, зробімо так само»

Звичайно ж отримувати досвід від колег важливо, але необхідно завжди розуміти, що ти робиш і навіщо. Завжди визначте ваші цілі, розумійте цінність потоку і тоді ви будете застосовувати круті технології там, де вони дійсно потрібні.

P. S. А може саме вам і не потрібний k8s?;)

Як треба:

  1. Аналіз та оцінка: при прийнятті рішень ґрунтуйтесь на аналізі та оцінці поточних потреб та проблем вашої команди чи організації. Не просто слідуйте модним трендам або думці інших людей, але адаптуйте технології та практики до своїх конкретних потреб.
  2. Цілеспрямованість: визначте свої цілі та розумійте, яку цінність та переваги принесе застосування певної технології чи методології. Переконайтеся, що обране рішення відповідає вашим цілям і допомагає досягти бажаних результатів.
  3. Інновації з розумінням: використовуйте нові технології та методи з розумінням та усвідомленням того, як вони працюють та які переваги вони пропонують. Навчайтеся та досліджуйте нові інструменти та підходи, щоб приймати поінформовані рішення.
  4. Прагматичність: будьте прагматичними у виборі та впровадженні технологій. Застосовуйте їх там, де вони справді вирішують конкретні проблеми та приносять цінність. Не застосовуйте їх просто через моду або сліпу імітацію інших.

«Ми моніторимо всі параметри сервера, у нас 1000 алертів ми знаємо все!»

Коли ви отримуєте мільйони подій від сервера, для команди підтримки це — просто спам, на який вже ніхто не реагує. Збирайте ключові параметри, не варто робити моніторинг того, на що ніхто не реагуватиме.

Як треба:

  1. Визначте ключові метрики: визначте найважливіші метрики, які відображають стан системи та можуть вказувати на проблеми. Фокусуйтесь на тих параметрах, які дійсно мають значення для вашої команди підтримки та бізнесу. Використовуйте ці метрики для моніторингу та оповіщення про проблеми.
  2. Порогові значення та алерти: визначте адекватні порогові значення для кожної метрики та встановіть оповіщення, які активуються лише при досягненні або перевищенні цих порогових значень. Це допоможе уникнути спаму та сфокусуватися на дійсно важливих подіях.
  3. Консолідація та агрегація: скоротіть кількість алертів, поєднавши схожі проблеми в одне сповіщення або групу. Наприклад, якщо кілька серверів мають однакову проблему, створіть єдине сповіщення, щоб уникнути дублювання та підвищити ефективність відгуку.
  4. Автоматизація та самозцілення: розгляньте можливість автоматизувати певні реакції на проблеми. Деякі проблеми можуть бути автоматично виправлені, наприклад, шляхом перезавантаження служби або автоматичного масштабування ресурсів. Це допоможе знизити навантаження на команду підтримки та прискорити вирішення проблем.
  5. Регулярний аналіз та оновлення: періодично аналізуйте ваш моніторинг та оповіщення, щоб переконатися, що вони, як і раніше, відповідають поточним потребам та проблемам. Вносити коригування та оновлення відповідно до розвитку системи та бізнес-вимог.

Дякую всім, хто дочитав до кінця, я сподіваюся цей досвід дозволить вам зробити менше помилок у майбутніх проєктах та починаннях. Бажаю вам успіхів!

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

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному11
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

рецепт як написати таку статтю — береш бест практіси і інвертуєш їх. Профіт. ;-)
той хто працював в кривавім ентерпрайзі розповів би аудиторї більш драматичні реальні анти-DevOps історії але або NDA не дозволяє або іспанський сором
але багато влучного вже сказано в далекому 2013-му DevOps Borat на твіттері
погугліть поржете

Розумний розподіл навантаження: важливо забезпечити баланс між обсягом роботи та можливостями команди. Розбийте завдання на дрібніші та пріоритезуйте їх відповідно до важливості і терміновості. Використовуйте методологію управління завданнями, такими як Agile або Kanban, щоб покращити планування та розподіл роботи.

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

Інкрементальні ітерації: рекомендується використовувати методологію розробки на основі інкрементів, таку як Agile або Scrum. Розділіть проєкт на дрібніші ітерації та плануйте досягнення конкретних цілей на кожній ітерації. Це дозволить керувати ризиками та краще контролювати якість змін.

В Agile-манфестові нічого немає про інкрементально-ітераційний підхід до розробки, також в залежності від особливостей проекту ви можете забезпечити інкремент через ітерації не тільки через Scrum, а й інші відомі фреймворки типу XP чи V-model.

P. S. А може саме вам і не потрібний k8s

Більшості компаній, які не готові вирішувати існуючі інженерні проблеми та контрібьютити в відповідні OSS спільноти, — він не потрібен.

Дякую за статтю.

Коли ви отримуєте мільйони подій від сервера

у-у-у-у-у, це те, від чого у мене завжди палає. Чомусь недалекі користувачі впевнені, що повідомлення про кожен чих в системі дозволить їм уникати помилок. Але від цього стає лише гірше.

Щоб не мати хибних очікувань, треба знати про Devops Engineer те, що він повинен займатись, як це не дивно, DevOps. Не налаштовувати чи масштабувати сервери, сервіси і мережі (привіт Infrastructure engineer), не будувати високодоступні системи і не займаєтись їх підтримкою (привіт, SRE), не роздає доступи і не допомагає з налаштуваннями (привіт, System Administrator). DevOps — це про пайплайни, білди, деплої, тести, оточення і SDLC. DevOps інженер — це частина команди розробки і працює в відповідному скоупі задач, але аж ніяк не окрема команда (як у Infrastructure чи Site reliability engineers).

DevOps — це про пайплайни, білди, деплої, тести, оточення і SDLC.

build engineer ?
DevOps — це взагалі не про людей, в про підходи у команді.

Саме тому я і відокремлюю в своїх твердженнях DevOps і DevOps engineer. Як і QA — це теж про підхід, а QA engineer — це фахівець, який цим займається.

DevOps і DevOps engineer

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

Мені було завжди цікаво як люди уявляють на практиці це поєднання:

Часті та маленькі мержі
Код-рев’ю: приділіть належну увагу процесу код-рев’ю.

Ні, я згодний з тим що великі мерж реквести потребують значних зусиль від рев’ювера. Але я краще витрачу більше зусиль раз на тиждень (умовно) ніж мене вся команда буде закидувати дрібними мержами кожен день.

Ну таки раз на тиждень нормально не поревювиш. Наприклад — кожного дня ревю по годині — тоді в пятницю потрібно 5 годин підряд.
Далі — швидше ревю — швидше фідбек. Можливо взгалалі не те зроблено. Чим швидше ревю — тим швидше виявиться проблема.
Взагалі чекати цілий тиждень на ревю — поправив код — потім знову цілий тиждень?
Сорі, але виглядає дуже неефективно...
Ревю — кожного ранку. Далі робота над своєю таскою.

як на мене все просто, якщо проект на умовному php/js — то є
SonarQube
phpmd
code style check
.....
просто манагери оперують стандартними фаразами, які прочитали в інтернеті :)

Нуу, я читав і мені не спало на думку таку залежність робити, бо про мержі все відносно сказано, тобто без прикладу наскільки «Часті та маленькі», що і в яку branch.

Код-рев’ю: приділіть належну увагу процесу код-рев’ю. Це дозволяє виявляти помилки, покращувати якість коду та обмінюватися знаннями в команді. Намагайтеся проводити код-рев’ю на ранніх етапах розробки та приділити достатньо часу на його виконання.

А до рекомендації стосовно код-рев’ю, якщо не виривати із контексту, то можна придиратися, бо якщо на складному проекті код-рев’ю — це части на QA та тестування перед CI, то з такою рекомендацією типу змінюємо процеси => ліквідовуємо код-рев’ю, а замість нього фактично буде практикуватися pair programming.

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

Ще зустрічав ’ у нас для ci/cd налаштовано тільки для деяких проектів’, а взагалі ми це не використовуємо

Пролистав до кінця, прочитаю пізніше.

Підписатись на коментарі