Підхід Keep The Lights On: як працює і чим корисний в розробці програмного забезпечення

Реліз IT-продукту — ще далеко не фінал проєкту. Життєвий цикл застосунку не закінчується його виходом у світ. Надалі слід підтримувати стабільну роботу системи, покращувати, розвивати функціонал. На цьому етапі стане в пригоді підхід Keep The Lights On (далі — KTLO).

Розповідаємо, що варто знати розробникам та менеджерам, щоб ефективно втілити принципи KTLO у проєкті.

Що таке KTLO в програмному забезпеченні

Під терміном Keep The Lights On мають на увазі будь-які процеси, що безперервно забезпечують стабільність і надійність програмного забезпечення та регулярне обслуговування його систем й інфраструктури. KTLO не додає нових функцій, проте фактично є серед завдань IT-команд і подекуди займає багато часу.

Які активності включає KTLO

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

Зазвичай KTLO охоплює такі завдання:

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

Що корисного з KTLO може винести для себе розробник

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

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

Підписуйтеся на наші соцмережі

Технічний борг є невіддільною частиною ітеративної розробки програмного забезпечення. Та до нього часто не доходять руки. А проактивний Keep The Light On дозволить інтегрувати в процеси час, наприклад, на проблемний код або зміни структури БД.

Ця методологія саме вже стирає межі між розробкою й підтримкою. Але з KTLO співпраця виходить на рівень, який дозволяє краще підтримувати стабільну роботу продуктів. Адже девелопери долучаються до створення пайплайнів CI/CD, оптимізації моніторингу, автоматизації тощо.

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

При цьому вся команда має розуміти, що таке KTLO. Лише так вдасться ефективно розподілити ролі, обов’язки та ресурси.

Наприклад, фахівці технічної підтримки можуть взяти на себе первинну обробку інцидентів та спілкування з користувачами. Операційні команди — сфокусуватися на обслуговуванні та підтримці сервісів, на забезпеченні доступності інфраструктури й розв’язанні типових, частих проблем. Розробники ж можуть за необхідності змінювати основний код, впроваджувати інновації та автоматизацію, закривати техборг. На менеджері проєкту, як правило, лежить відповідальність за виконання всіх етапів.

З чим допоможе KTLO в управлінні проєктами

Виокремлення KTLO на рівні тасків та звітів допоможе побачити, скільки часу займають рутинні задачі. Наприклад, такі IT-лідери, як Google, вважають: коли на підтримання стабільності уходить понад 50% часу розробників, це вимагає переорієнтації в роботі організації.

Якщо на завдання KTLO йдуть мало не основні зусилля розробників, це є приводом для створення окремої команди. Це виправдано, коли мова про високонавантажені системи, які активно зростають. Наприклад, стартапи, які вийшли на стабільний рівень.

Завдяки концепції KTLO компанія краще усвідомлює цінність кожної дії. Наприклад, окремі задачі з підтримки системи є критичними та не можуть бути відкладені. А інші можна виконати пізніше, бо в черзі стоять важливіші нові функції.

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

Робота KTLO в організаціях може бути «нічиєю». Розробники перекидають її на операційників, ті на техпідтримку, та навпаки. Але щоб підтримувати стабільну роботу системи, треба знати, хто за що відповідає та за необхідності додавати ролі: від девопсів і SRE-інженерів до KTLO-команд.

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

Коли потрібна команда для KTLO

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

Створення команди для KTLO буде виправдано, коли:

Пам’ятайте: навіть за наявності всіх факторів варто фінансово обґрунтувати переваги команди, яка буде підтримувати стабільну роботу. Показати її цінність та доцільність допоможе індекс ROI (Return on Investment). Як це виглядає на практиці?

Наприклад, вам треба порахувати скільки коштуватиме залучення розробників до активностей KTLO на певний період, окрім базового проєктного навантаження. Потім визначити, скільки втрачає бізнес від простоїв за той же час, спрогнозувати розмір та бюджет KTLO-команди. Зазвичай рейт цих фахівців нижчий за середні по ринку пропозиції для досвідчених девелоперів. Розрахунки можна співставити з потенційною вигодою для проєкту (наскільки від KTLO залежить втілення інновацій). Порівнявши показники, ви зрозумієте, чи є фінансово виправданим створення додаткової команди.

Як побудувати процеси KTLO на проєкті

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

Може здатися, що KTLO — це рутинні, операційні задачі, переважно менеджерські. Але виконувати їх має саме розробник програмного забезпечення. Йдеться не про малий бізнес чи стартапи, де немає додаткових ролей в команді. Сучасні системи, особливо на мікросервісах, з часом збільшуються, стають складнішими. Відповідно, ризик небажаних інцидентів у них зростає, вимоги до безперебійної роботи сервісів стають суворішими. Все це потребує глибокого розуміння продукту, його технічних особливостей, поведінки, а також вміння вчасно помітити й пофіксити проблему.

Тож не зволікайте, практикуйте KTLO та покращуйте свої розробки!