Сразу уточню - всё описанное в этой статье касается опыта работы только в небольших компаниях и командах, занимающихся разработкой ПО.

Терминология

  • Release velocity - частота выпуска новых версий
  • SLI - Service Level Indicator - какие-либо метрики у проекта. Можно считать числом тикетов к техподдержке, дробя на алерты/человеческие заявки, серьёзные баги, можно считать уход-приход клиентов.
  • SLO - Service Level Objective - цели, то есть значения SLI к которым надо стремиться.
  • SLA - Service Level Agreement - соглашения с клиентами по значениям SLI, при выходе за которые возникает какая-либо конфликтная ситуация, где ваша компания - мудак и не держит обещания.

О ситуации

Ситуация: живёт себе проект, но мир вокруг него меняется. То, что было приемлемо 5 лет назад кажется “ахаах, ща бы такую халяву”. То, что было рабочим и правильным в любой момент может притащить пак проблем, которые надо решать, а решаются они за счёт времени разработки новых возможностей. Это не совсем ок.

Что можно взять из опыта крупных компаний

Мне очень нравится пирамида потребностей SRE приведённая в SREBook от google:

Site Reliability Hierarchy

Вещи в этой пирамиде хорошо ложатся на крупную компанию с большим числом людей. В небольшой команде/стартапе ресурсы сильно ограничены.

Из неё я бы выделил несколько вещей, которые подходят и небольшим командам из 2-5 людей:

  • Мониторинг
  • Тестирование
  • Постмортемы

И 20% усилий, потраченных на них, убьют 50% других усилий и рутины.

Чего стоит добиться, чтобы жизнь стала лучше

Обеспечение разработчиков/инженеров следующими возможностями сделает жизнь проекта здоровее в разы

Возможность быстро выкатить хотфикс

Косяки проходят мимо тестов. С этим надо смириться, полностью от этого избавиться не получится до тех пор, пока мы не являемся киборгами с неограниченными ресурсами.

Здесь нас спасёт любой более менее внятный подход к работе с гитом. Отсюда текут все плевки на “пушить в мастер”. Отсюда же причина, по которой feature-ветки нужно мержить в release, а не в master.

Обнаружение деградаций

Нагрузочные тестирования + мониторинги/сборы статистик, в том или ином виде, даже если это кажется костылями, с сохранением истории и возможностью просмотра статистики за последние полгода-месяц-неделю - замечательная штука. Важный совет, который хотел бы дать - замеры надо проводить как на высоких уровнях, так и на низких, чтобы быстро узнать когда и что именно ухудшилось.

Наличие тестов

Ты не можешь быстро двигаться, когда не уверен. Вспомним про хотфиксы - выкатывать хотфикс без тестов зло, если это имеет чрезвычайную срочность, иметь возможность запустить ХОТЯ БЫ 2-5 минутные smoke-тесты и убедиться что вы не переломали всё вхлам - это уже снизит вероятность того, что вы сделаете только хуже.

Вообще на моей практике довольно самые крупные факапы возникали в процессе торопливого исправления других факапов. Помимо тестов поможет спокойствие, но как это контролировать - я не знаю. Когда чувствуете, что уровень стресса повышается - лучше попросить чьей-нибудь помощи. Во-первых может быть станет спокойнее, во-вторых ваши действия будут контролировать.

Ещё пара наблюдений

Приоретизируйте!

Да, любой disaster это критическая задача. Есть такая фраза, которую я слышал не помню где:

Когда все задачи критические - нет ни одной критической задачи.

Тут можно спорить, что даже когда их много - их критичность для бизнеса не снижается. Но одновременное решение нескольких задач никогда не приводит ни к чему хорошему. Приоретизация каждый раз при выборе следующей задачи и концентрация на ней - лучше что вы можете сделать. Выбирайте или просите представителей бизнеса помочь выбрать то, с чего нужно начать.

Предотвращайте!

Второе - делайте заглушки в продукте, которые предотвратят возникновение таких косяков или сами решат проблему при их возникновении. Это должно включаться в задачу по решению временных проблем. В противном случае вы будете всю жизнь заниматься разгребанием рутины и никогда не дойдёте до разработки фич. Если вы откладываете создание этой заглушки и переключаетесь на другую важную критическую проблему - создайте себе задачу в jira.

Анализируйте!

Если пишите постмортемы после решения проблемы - здорово. Если вы их потом читаете совместно - ещё лучше, вы сможете выяснять самые проблемные места проекта, отнимающие больше всего времени от разработки фич и потратить некоторое время на то, чтобы сделать их надёжнее.

P.S.

Имелось в виду сохранить возможность хоть как-то релизить софт в такой тяжелой обстановке, когда всё вокруг взрывается и ничего с этим не поделать, а не держать её на постоянном уровне.