Ефективний DevOps під час війни: український кейс

«Війна прийшла в наш дім дуже несподівано вранці, коли ми йшли на роботу. За кілька тижнів війна стала для нас новою нормою».Так розпочав свою промову на DevOpsDays Ukraine Олег Миколайченко. Киянин пройшов шлях від служби підтримки до старших ролей у DevOps. 

Зараз він керує командою на посаді Head of Infrastructure у компанії SQUAD, яка займається системами безпеки машинного навчання. «…я добре знаю, як виглядають інциденти з різних точок зору, у різних компаніях і підприємствах», — стверджує Олег.

Плани компаній на випадок надзвичайних ситуацій зазвичай не враховують російське вторгнення, але Олег вважає, що SQUAD був приблизно на 80% готовий до повномасштабної війни завдяки організації безперебійної роботи та управління інцидентами. Розкажемо, про що було його промова.

Коли трапляється найгірший інцидент

«Вже немає часу. Ви не можете нічого змінити. Ви не можете додати нові документи. Ви не можете вибудувати нові процеси. Ви не можете додати більше даних до Runbook. Ви не можете створити зустрічі для обміну знаннями. Ви не можете тестувати резервні копії. Ні в якому разі, у вас немає часу. Тому що найбільший і найстрашніший інцидент уже відбувся», – сказав Олег, який прокинувся від російських обстрілів 24 лютого 2022 року.

Близько тисячі співробітників по всьому світу швидко об’єдналися навколо однієї інструкції від директора з розробки SQUAD: «Поки ви не досягнете місця, де почуватиметеся в безпеці, не переймайтеся через роботу».

У SQUAD передбачали можливість нападу, тому надали співробітникам список ймовірних небезпечних зон і укриттів компанії. Невдовзі вони відкрили офіси в Румунії й Польщі та розповіли, як правильно сплачувати податки та дотримуватися місцевих законів. А для тих, хто залишився в Україні, SQUAD створила групу волонтерів і намагалася забезпечити потреби колег, які приєдналися до сил оборони.

Команда SQUAD створила бота з відкритим кодом, який перевіряв у співробітників:

  • чи вони у безпеці;
  • чи готові вони до роботи фізично та морально;
  • чи працює в них інтернет.

Так компанія швидко дізнавалася про стан справ у співробітників і чи є якісь можливості для роботи інженерів.

«Ключове значення тут має довіра. Ніколи не тисніть на своїх колег, тому що вони перебувають у стресі й докладуть усіх зусиль [в роботі], коли зможуть убезпечити себе та [допомогти] своїм сім’ям знайти безпечні місця», — сказав Олег. Якщо щось станеться з вашими колегами, буде набагато гірше, ніж будь-що у вашій системі управління інцидентами до цього.

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

Олег також відчув, що він повинен допомогти своїй команді знайти способи «зробити свій внесок у перемогу, тому ви повинні поділитися своїм баченням того, як кожен член команди може зробити внесок у велику українську перемогу».

Як створити план безперервної роботи бізнесу

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

«Визначте найбільш критичні місця, щоб знати, що ви зосереджуєте зусилля в потрібному місці», — підмітив Олег Миколайченко. «Вам не потрібно витрачати час на некритичні оповіщення та шумні попередження».

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

Керівник команди також відповідає за забезпечення безперервності бізнесу, що включає:

  • Постійну синхронізацію з внутрішніми та зовнішніми стейкхолдерами.
  • Відстежування показників разом з часом прийняття запиту та часом на його вирішення.
  • Готовність втрутитися та працювати практично з найважливішими завданнями.
  • Створення нового формату оцінки та вимірювання показників проєкту через призму нової воєнної реальності.

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

Після встановлення нового балансу між роботою та війною SQUAD двічі перевірили часові пояси команд та встановити доступні робочі часові інтервали. У компанії створили новий графік чергування на IaC на базі Terraform, який інтегрували до вищезгаданого бота.

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

Як налаштувати план аварійного відновлення

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

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

  1. Визначте критичні процеси та операції. Які збої сильно вплинуть на працездатність вашого бізнесу? 
  2. Оцініть сценарії аварій. Визначте свої пріоритети, цілі відновлення та часові рамки.
  3. Складіть план спілкування. Призначте ролі конкретним людям і відділам.
  4. Розробіть план резервного копіювання та відновлення даних. Як виправляти, стримувати та відстежувати будь-які втручання у роботу.
  5. Перевірте свій план. Знайшли недолік? Додайте будь-які кроки для підвищення ефективності.

Runbooks для оповіщення

За словами Олега Миколайченка, ще однією умовою для якісного планування на випадок надзвичайних ситуацій є збережені як код Runbook у поєднанні з детальними інструкціями, зокрема:

  • Як працювати зі сповіщеннями.
  • Де знайти додаткові відомості, документацію, дані, схеми архітектури та інформаційні панелі.
  • Як під’єднуватися до систем.
  • Як виправляти несправності.
  • Як приймати сповіщення та повідомляти про виправлення.

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

Створіть шаблон для Post Mortem інцидентів 

У разі збоїв обов’язково проводяться так звані Post Mortem, але в кризовому режимі краще робити їх максимально простими. Ви повинні створити свій власний шаблон Post Mortem, але бажано не використовувати шаблони від «гігантів», таких як Google, або шаблони з відкритим кодом — «оскільки зазвичай вони занадто великі, і ви витрачаєте час на заповнення всіх необхідних пунктів, щоб слідувати методології, але вам точно не до цього. Навіть під час кризи намагайтеся зосередитися на речах, які мають значення», — вважає Олег Миколайченко.

Зосередьтеся на питаннях, які безпосередньо впливають на бізнес, та прагніть виміряти такі показники, як:

  • Скільки користувачів постраждало?
  • Чи можете ви оцінити грошові втрати?
  • Які сервери постраждали?

Олег радить розробити рівні тривоги, щоб вирішити, наскільки терміново виправляти той чи інший інцидент. Він каже, що коли ви засвоїте такі практики Post Mortem, ваша команда зможе розширювати та автоматизувати такі дослідження, щоб знайти більше першопричин і копати глибше. Олег впевнений, що його команда більш ретельно досліджуватиме Post Mortem, коли війна закінчиться.

Як створити самокеровану команду

Роль лідера команди під час війни полягає в тому, щоб переконатися, що його підлеглі є самодостатніми. Ваша команда повинна знати, що робити, коли ви офлайн з будь-якої причини:

  • Як виконувати поточні задачі без вас: від кік-офу до звіту за результатами роботи.
  • Як брати тікети з беклогу.
  • Як правильно розставляти пріоритети.
  • Яка процедура звітності.

Після утворення самокерованої команди, ви будете потрібні для складніших і цікавіших питань високого рівня, як-от допомога у навчанні наступних лідерів команд.

«Створення самокерованої команди є найскладнішою частиною обов’язків керівника команди, тому що завжди є антипаттерн ставлення до своєї команди як до дитини», — попереджає Миколайченко.

Самовідновлювальна архітектура

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

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

«Резервні функції можуть запобігти простою і втраті даних», — також рекомендував він. Ефемерні контейнери та планувальник Kubernetes знадобляться для самознищення та створенні нового поду.

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

Майте план на випадок аварії:

  • Визначте межі обслуговування;
  • Використовуйте саморегулювання;
  • Розгляньте альтернативні види ресурсів.

Стандартизуйте:

  • Запровадьте універсальний інструментарій
  • Збирайте діагностику, орієнтовану на події;
  • Надайте всім повну видимість.

Потрапляйте в аварію красиво:

  • Перенаправляйте і не блокуйте;
  • Автоматизувати відомі вам рішення;
  • Повідомте людину про інцидент.

«Ніщо не може бути таким важким, як управління інцидентами, якщо ви перебуваєте в ще одному величезному інциденті», – сказав Олег Миколайченко у кінці своєї промови.

Наша з вами задача — працювати та робити все, щоб Україна вистояла. Робіть свою роботу якісно, вчиться нового та дбайте про український бізнес. І не забувайте допомагати нашим силам оборони. Бережіть себе та свої інфраструктури.

Залишити відповідь

Дякуємо, що поділились