Підхід Keep The Lights On: як працює і чим корисний в розробці програмного забезпечення
Реліз IT-продукту — ще далеко не фінал проєкту. Життєвий цикл застосунку не закінчується його виходом у світ. Надалі слід підтримувати стабільну роботу системи, покращувати, розвивати функціонал. На цьому етапі стане в пригоді підхід Keep The Lights On (далі — KTLO).
Розповідаємо, що варто знати розробникам та менеджерам, щоб ефективно втілити принципи KTLO у проєкті.
Що таке KTLO в програмному забезпеченні
Під терміном Keep The Lights On мають на увазі будь-які процеси, що безперервно забезпечують стабільність і надійність програмного забезпечення та регулярне обслуговування його систем й інфраструктури. KTLO не додає нових функцій, проте фактично є серед завдань IT-команд і подекуди займає багато часу.
Які активності включає KTLO
З одного боку, ці заходи покривають реактивні задачі, тобто реакцію на інциденти. З іншого — проактивні дії, де основний фокус на попередженні проблем та зменшенні навантаження девелоперів.
Зазвичай KTLO охоплює такі завдання:
- Підтримка інфраструктури. Базовий рівень — сервери, мережа, операційна система, бази даних. Потрібно їх моніторити, оновлювати та гарантувати безпеку.
- Створення резервів. На проєкті мають бути інструменти резервного копіювання даних та розгортання IT-ресурсів для масштабування системи.
- Моніторинг системи. Варто відстежувати проблеми з продуктивністю, аномалії, збої, налаштовувати сповіщення та швидко реагувати на інциденти.
- Виправлення помилок. Будь-яке програмне забезпечення має баги. Треба виявляти їх та виправляти для мінімізації простою системи.
- Стандартні оновлення. Це покращення на кшталт встановлення патчів безпеки та адаптування продукту/сайту під зміни партнерських API — все задля підтримки стабільної роботи.
- Забезпечення відповідності корпоративним політикам. В ідеалі будь-яка компанія повинна оновлювати продукт, враховуючи норми безпеки, корпоративні політики, вимоги державних регуляторів тощо.
Працюючи за моделлю KTLO, важливо пам’ятати про цінність балансу між реактивністю та проактивністю. Не існує систем, де не буває інцидентів, але не можна реагувати виключно на проблеми. Попередити прогалини в безпеці коштуватиме значно менше, ніж долати наслідки, а вони бувають надто критичними для проєкту.
Що корисного з KTLO може винести для себе розробник
- Краще розуміння системи
Розробники, на відміну від операційників, знають особливості й обмеження архітектури продукту, глибше розуміють бізнес-логіку та розбираються в сотнях залежностях у коді. Розв’язання деяких задач без таких знань неможливе.
- Ефективність виправлення багів
Через складність систем деякі помилки важко або занадто довго долати на рівні технічної підтримки. Адже можуть бути потрібні структурні зміни в коді, які позбавлять від повторення інцидентів та гарантують стабільність.
- Закриття технічного боргу
- Інтеграція з DevOps
Ця методологія саме вже стирає межі між розробкою й підтримкою. Але з KTLO співпраця виходить на рівень, який дозволяє краще підтримувати стабільну роботу продуктів. Адже девелопери долучаються до створення пайплайнів CI/CD, оптимізації моніторингу, автоматизації тощо.
- Розробка нових функцій
KTLO додає структурних змін в процес розробки, що допомагає швидше впроваджувати основні інновації у програмне забезпечення. Наприклад, в довгостроковій перспективі може покращуватись інфраструктура розробки та регулярно проводитися рефакторинг.
При цьому вся команда має розуміти, що таке KTLO. Лише так вдасться ефективно розподілити ролі, обов’язки та ресурси.
Наприклад, фахівці технічної підтримки можуть взяти на себе первинну обробку інцидентів та спілкування з користувачами. Операційні команди — сфокусуватися на обслуговуванні та підтримці сервісів, на забезпеченні доступності інфраструктури й розв’язанні типових, частих проблем. Розробники ж можуть за необхідності змінювати основний код, впроваджувати інновації та автоматизацію, закривати техборг. На менеджері проєкту, як правило, лежить відповідальність за виконання всіх етапів.
