Если тебе платят деньги, значит, твоя работа зачем-то нужна

Но как понять её ценность, если ты не создаёшь выручку?

У любого бизнеса есть миссия и цель. Миссии бывают разные, цель всегда одна: извлечение прибыли. Если ты маркетолог, или продажник, то напрямую наливаешь деньги в кассу. В этом случае всё понятно: выручка минус расходы == прибыль. 

Но что если ты — технарь? Разработчик пилит фичи, по сути реализует бизнес-процессы, которые также зарабатывают деньги. 

Но если твоя работа на фичи не завязана, или состоит не только в этом? Или ты и вовсе не разработчик, а DevOps, SRE, QA, безопасник и так далее? 

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

Привет! Меня зовут Степан и я занимаюсь управлением техническими рисками в онлайн бизнесах. Эта статья — практическое руководство о том, как определить ценность твоей работы, научиться измерять её практическую пользу и управлять целями, если ты не приманиваешь деньги напрямую на расчетный счет.

Что ты получишь, за 15 минут своего времени?

Мы вместе попытаемся понять, за что получают деньги те сотрудники, которые своей работой напрямую не генерируют выручку и набросаем простенький data-driven подход (ну мы же технари, в конце-концов), чтобы систематизировать понимание о том:

  • А что вообще есть такого важного в бизнесе кроме входящего потока денег?

  • Как нам это всё наглядно разложить, измерить, приоритезировать?

  • Как выстроить работу так, чтобы фокусироваться на том что важно, а не на всём подряд, или чём попало?

  • Как прикинуть сроки, а в ретроспективе ещё и потрекать прогресс, да рассказать всем какие мы (ну или они) молодцы?

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

Потом посмотрим, насколько легко подружить его с простеньким фреймворком целеполагания, под названием OKR (или любым другим - у кого на что рука набита).

Ну и в процессе научимся управлять рисками на минималках — без этого вообще никуда.

А «мы» - это кто? 

  • Инфраструктурные инженеры всех мастей, как ты их ни назови;

  • QA;

  • безопасники; 

  • тимлиды технических команд;

  • руководители отделов и направлений;

  • технические директора

  • и даже (сюрприз) разработчики!

Давай сразу договоримся: если ты на самом деле искренне убеждён, что твоя работа состоит в том, чтобы вовремя закрывать таски, а всё остальное решат ответственные взрослые — ничего для себя полезного ты отсюда не вынесешь. Дальше можно не читать — у тебя всё хорошо.

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

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

Итак, тезисно

Если коротко и грубо, то наша цель — понять что делать, как и когда. 

Ну или за что хвататься раньше - что важно, а что нет. И насколько важно.

И плясать мы будем от«зачем» — от того, что важно для бизнеса — того для чего н��с нанимали, для чего нанимаем мы и за что всем нам платят деньги.

Ну а покуда расчётный счёт вне зоны наших компетенций, ответственности и полномочий, а платят нам за риски, то первым делом мы разберёмся что же это за риски такие и на какие группы (давай дальше использовать слово “домены”) их можно поделить:

  • Надёжность: Было бы здорово, если бы всякий важный бизнес-процесс (будь то депозиты/выплаты курьерам в доставке, поиск и заказ такси, ставка на спорт, или формирование/выставление ордера в трейдинге) выполнялся вовремя, всегда и правильно.

  • Безопасность: Если нас не поломают, не уведут деньги, данные клиентов не окажутся на профильных форумах, а Visa & MasterCard не перестанут с нами дружить из-за пофейленного аудита по PCI-DSS - будет вообще здорово.

  • Рыночная гибкость: Если в нашем весёлом такси кнопку «поездка с животным» мы будем делать год, в то время как условный Uber выкатит её за неделю, боюсь пресловутой выручке (на которую мы же вроде как и не влияем) очень даже от нас достанется. Точно также случится, если мы не сумеем справиться с возросшим спросом после успешной маркетинговой компании (или большого сбоя у главного конкурента), или не выйдем в новый регион, в то время как наши друзья по рыночной нише уже там.

  • Косты: Выручка-выручкой но если предыдущие три пункта стоят столько же - сколько легло на расчётный счёт, или даже больше, то прибыли нам не видать. В отличие от выручки - на прибыль мы ещё как влияем. Как минимум через чек на $500k от Гугла/Амазона и свои более чем скромные $8—12k из фонда оплаты труда. 

  • Operational Excellence (термин я присмотрел у AWS из их “Well-Architected Framework”): На этот пунктик чувакам от бизнеса — скажем прямо — как правило плевать с высокой колокольни. До поры до времени. Пока не стрельнет.

    • “- Почему новые сотрудники ждут доступов уже две недели?”

    • “- Третий час лежим — сколько осталось?”

    • “- Это же просто строчка в конфиге — если она будет ехать на прод ещё одну неделю мы сорвём аудит на банковскую лицензию и будем ждать следующего года”

    • “- Админы п^%#&ы!”.

Знакомо?

И ведь они правы: в собственной кухне понаворотили такого гомункула из мудрёных и подчас самописных (признавайся — узнал себя?) инструментов, и четверных код-ревью с подвыпедвертом и вкусовщиной, что процесс управления изменениями превратился во что-то, ну, в лучшем случае, анекдотическое.

А зачастую и вовсе обслуживание пресловутых инструментов подменило собой их использование.

Не говоря о том, какую долю та самая «строчка в конфиге» заняла в ФОТ за этот месяц.

Причём тут SRE?

SRE — это такой прикольный и простой способ принимать верные решения: померять то, что важно, чтобы делать то, что нужно, да ещё и вовремя.

Но у SRE в том виде, в котором нам с тобой его подают в большинстве заведений, есть один большой недостаток: строгий фокус на надёжности, минуя всё остальное.

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

Для начала просуммируем что такого важного у нас получилось выше, а затем подумаем как это измерить, и сравнить:

  1. Надёжность. Пускай она, пока что, включает в себя:

    1. стабильность бизнес процессов,

    2. их своевременность,

    3. и корректность;

  2. Безопасность, в свою очередь:

    1. секьюрити риски и то как мы с ними управляемся,

    2. инциденты и нашу прыть в реагировании;

  3. Рыночная гибкость:

    1. Time to Market,

    2. и масштабируемость — ту что про бизнес;

  4. Расходы — как минимум:

    1. чек от провайдера;

    2. твоя зарплата;

  5. Operational Excellence:

    1. Характеристики времени, или усилий (банальное количество операций для достижения результата — очень эффективная и наглядная метрика — часто даже лучше чем время) для:

      1. хотя бы топ 3-5 конкретных типовых рутин;

      2. нашего Change Management процесса;

      3. планов реагирования на инциденты и катастрофы (IRP, DRP).

Сказал что нам платят за риски, а сам засунул риски в безопасность — ну как так?

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

А ещё когда мы дойдём до метрик, станет очевидно, что говоря про риски надёжности было бы здорово меряться ещё и отказоустойчивостью. Но мы и к этому вернёмся чуть позже.

Ну а теперь длинно

  1. Где-то две трети текста мы поговорим о том что и как можно измерять, и как нам натянуть SRE на всё что для нас важно;

  2. А в самом конце - об OKR и о том как бы нам так поженить целеполагание со SRE на простых примерах.

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

Так-что её может и не стоит вот прям вычитывать от начала и до конца, а лучше подойти к вопросу кусочно.

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

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

Структура тут следующая:

  • Что, как и в каких попугаях можно мерять

    • надёжность;

    • безопасность;

      • здесь мы в первый раз поговорим про риски - мне просто так удобнее создавать этот текст;

    • рыночная гибкость;

    • косты;

    • operational excellence;

  • Что делать с тем что мы там намеряли

    • вводная о том чем заменить “R” в “SRE”;

    • надёжность;

    • безопасность;

    • рыночная гибкость;

    • косты;

    • operational excellence;

  • И в финале - снова про риски, но уже применительно ко всему вышеперечисленному.

Итак. Мы разобрались с тем, что у нас вообще есть. Теперь коротко о том, как и чем всё это измерять.

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

Помчали.

Меряем надёжность

Это самое простое — тут мы можем просто натаскать материал из SRE-литературы как есть.

  1. стабильность: меряем рейтом ошибок — отношением неуспешно выполненных транзакций к их общему числу: Error Rate == Errors / Requests * 100

  2. своевременность:

    1. временем, затрачиваемым на каждую транзакцию нашего БП: Duration (или Latency)

    2. и количеством транзакций, которое мы можем выполнить в единицу времени, не роняя стабильность и корректность ниже приемлемого для нас уровня; Requests (или TPS)  по результатам нагрузочного тестирования (и никак иначе).

  3. корректность: вот это интересная и не очень лёгкая история — из опыта мне встречалось два варианта:

    1. Некоторые умеют валидировать транзакции постфактум — утюжа условную БД транзакций некоторым валидатором.

    2. Другие считают и трекают обратную связь от своих клиентов и дальше уже с этим разбираются.

  4. отказоустойчивость:

    1. RPO & RTO — это вообще царь-метрики. Если у вас вообще ничего нет, но есть понимание что ближайшие полгода-год цели, планы и результаты нужно ориентировать на улучшение надёжности, то от этой парочки плясать проще всего;

    2. риски — конкретику дам в финале, а пока давай поговорим о них в разделе про секьюрити.

  5. инциденты:

    1. количество по ущербу/severity;

    2. MTTD (mean time to detect);

    3. MTTR (mean time to resolve).

Несложно пока, правда? Ничего нового не сказал. Погнали дальше.

А что насчёт даунтаймов?

А то что мы обычно называем даунтаймом, вполне-себе смахивает на частный случай нарушения стабильности, в котором рейт ошибок достигает 100% сразу по всем критичным БП.

Так что, если быть честным с собой, то за даунтайм стоило бы считать любой выход за приемлемое количество н��успешных транзакций, даже в одном из критичных БП. А не только те ситуации, где  на каждые 100 транзакций всех БП пришлось по 100 отказов. И не забывать, что транзакция отработавшая успешно, но дольше чем хотелось бы - это тоже неуспех.

Таким образом, не считая корректности, доступность каждого БП для пользователей/контрагентов может характеризоваться суммарной долей транзакций, которые:

  • либо вернули неуспешный статус;

  • либо заняли больше времени чем требуется.

И прежде мы поедем дальше - ещё одна крошечная ремарка о том что такое “вернули неуспех” и что такое “дольше чем требуется”.

В простейшем случае, если у нас например REST API - мы можем считать за неуспехи те запросы что вернули клиенту ошибочные HTTP статусы. Собирая данные об этом например с балансера с которым клиентская сторона непосредственно взаимодействует.

А за долгие транзакции, в свою очередь, те из них, что показали неудовлетворительный latency на том же балансере.

Для начала, или PoC вашей технической реализации этого более чем достаточно.

Внимательный читатель задаст тут минимум два вопроса:

  1. а что если запрос до балансера вовсе не дошёл? (DNS не отрезолвился, или отрезолвился не туда, или соединение не удалось установить)?

  2. а что если запрос дошёл, latency и статус в порядке, но:

    1. перед этим тот же DNS, или коннект заняли для клиента в 10-100 раз больше времени?

    2. у нас не REST API, а обычная такая-себе веб страница и после быстрого ответа бэкэнда клиент дооолго грузил CSS-ку, или недополучил какой-нибудь JS и на его стороне при успешном ответе нашего бэкенда всё-равно ничего нормально не отработало?

Крч тут можно много фантазировать.

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

Поэтому в частном случае стоит озадачиться вопросом о том откуда и как собирать информацию для конкретной технической реализации конкретного бизнес процесса.

Где-то действительно будет удобно и близко к истине собрать данные с балансера. Где-то то же самое актуальнее будет получить с условного CloudFlare/Qrator и т.п.;

Для кейсов с веб-страницами, или мобильными приложениями возможно лучше подойдёт какое-либо RUM решение - от Pingdom/NewRelic/Datadog и т.п., которое соберёт и отдаст данные об успехе/неуспехе и затраченном времени прямо с пользовательского устройства - JS-кой из браузера, или инструментацией из мобилки.

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

Всё, с надёжностью пока покончили, двигаемся дальше.

Меряем безопасность

Тут хитрее. Как-то изучая тему и пытаясь выяснить «а как у людей» я находил было что-то вроде такого: «мы меряемся количеством инцидентов».

Я люблю наивные вопросы. И вот мне интересно: а если инцидентов в Q2 меньше чем в Q1, это мы хорошо поработали, или «они» плохо?

А если вовсе не было, значит ли это, что у нас всё здорово, а инцидентов и дальше не будет?

Бросается в глаза, что такая метода чересчур ретроспективна и зависит не особо-то и от нас. 

А как бы нам в будущее заглянуть и понять, что в Q2 оно выглядит вот настолько-то попугаев безопаснее чем было в Q1?

  1. Инциденты: их оставим в качестве метрики раз уж начали. Трекаем:

    1. количество по severity/ущербу;

    2. MTTD (mean time to detect);

    3. MTTR (mean time to resolve);

  2. Уязвимости: когда мы говорим о рисках компрометаций, утечек, или потерь - метрика то что надо; Где мерить и чем:

    1. исходный код, который мы создали: SonarQube, PVS Studio etc.

    2. библиотеки которые он использует: OWASP DepCheck, Aikido

    3. пакеты ОС в среде которой выполняются наши приложения:

      1. Docker-образы: Snyk, интеграция ECR с Inspector в  AWS и т.п.

      2. Compute инстансы: AWS Inspector + AWS Systems Manager, в гугле наверное тоже что-то есть;

    4. мисконфигурации (в том числе мискомплайенсы):

      1. в инфре: AWS Inspector + AWS Config - наборы правил, в том числе по PCI-DSS и т.п.; В GCloud тоже что-то такое обязано быть;

      2. в кубе: OPA Gatekeeper, Kyverno - тоже с готовыми наборами правил, тоже включая комплаенсы и бест практисы навроде CIS

    5. Трекаем количество по

      1. severity

      2. времени жизни

    6. При целеполагании и планировании выбираем наиболее выгодные по соотношению цена/критичность;

  3. Риски:

    1. если у нас вовсе нет известных уязвимостей и не было инцидентов - значит ли это, что с безопасностью всё ок и ничего не случится?

    2. а если всё-таки случится - как бы нам так посчитать насколько последствия в Q2 окажутся менее драматичными чем случись то же самое в Q1?

    3. Берём любой простецкий курс-ликбез по управлению рисками из интернета. “Риск Академия” в Ютубе норм; Смотрим: что такое выявление рисков, что такое матрица рисков, что такое метод галстук-бабочка.

    4. Не упарываемся - наша цель не регуляторам реестр рисков показать. Наша цель: понять “ок/не ок” и посчитать насколько станет менее “не ок” если “нам”/”вам”/”им”/”всем нам” сделать такую-то работу;

    5. Выделяем хотя бы критичный верхнеуровневый минимум - например: утечка данных, компрометация приложений, компрометация инфры, инсайдерская активность сотрудников (намеренная или нет), пофейл комплаенса;

    6. CISO скажет, что такой список - не более чем возможные причины, а настоящие top-level риски - это раскрытие, изменение и утрата бизнес-данных (пользовательских, или нет); Юрист возразит: это тоже всё лишь факторы, а риски - это регуляторные санкции - штрафы, операционные ограничения и т.п.: Для CEO топ левел будет скорее всего выглядеть как: снижение прибыли и замедление роста бизнеса;

    7. Вывод намба ван: набор топовых рисков очень зависит от того кто именно на них смотрит. И так как мы всё-таки технари - я предлагаю нам фокусироваться именно на технических рисках;

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

    9. Риск можно снижать влияя на его вероятность или на ущерб к которому он ведёт;

    10. Поэтому работаем с вероятностями и ущербами:

      1. можно просто посчитать факторы влияющие на вероятность и ущербы для каждого риска. Вот прямо по головам;

      2. можно использовать специализированные инструменты: калькулятор от OWASP - годный пример - открой, посмотри прямо сейчас;

    11. Трекаем количество по Severity;

    12. При целеполагании и планировании выбираем наиболее выгодные по соотношению цена/критичность.

Про риски

В ютуб сходил? В GPT? Ну всё — теперь ты умеешь управлять рисками.

К примеру риск компрометации веб-приложения можно разбомбить как-нибудь вот так:

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

А если нужно сравнивать риск с самим собой (“до” и “после”) - то можно оценивать его место в матрице просто количеством фактором и ущербов - почему нет?

В примере выше у нас есть риск с 12-ю факторами повышающими вероятность его наступления и 12-ю пунктиками ущербов.

Мы можем значительно снизить фактор “Успешная попытка компрометации” разместив перед нашим веб-приложением WAF. Утрату данных (удаление, или шифрование) и их изменение подстраховать неизменяемой резервной копией. Риски развития атаки и утечки данных снизить ограничив нашим приложениям возможность устанавливать сетевые соединения во внутренней сети и ходить в Интернет при помощи сетевых политик. И вот уже из 12x12 у нас получилось 11x4. И т.д.

Всё - вот теперь самое время вытащить эту тему из домена безопасности: в конце-концов мы с неё начали и платят нам именно за риски.

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

К примеру у нас есть риск “превышение RTO при отказе региона” в AWS/GCP. На дистанции в год-другой вероятность подобного события можно смело оценить в единицу ) А если наш бизнес связан с финансами - платежи, или трейдинг, то приемлемым запросто может быть RTO “< 1 минуты”. Ну и главный фактор риска тут выглядит примерно как “не сумели переключиться на резервную инфру в приемлемое время”.

Может быть потому что долго её поднимали, может быть потому что процедура переключения сложная и требует человеческого вмешательства. Это наши факторы второго уровня. И отсюда мы уже можем строить принятие решений.

Допустим - вместо желаемых “<1 минуты” мы по факту имеем “<10 минут”. Мы можем сравнить финансовый ущерб от лишних 9 минут простоя со стоимостью внедрения и владения инфрой по схеме Active-Active и понять будут ли эти 0 минут вообще рентабельны.

Думаю принцип я более-менее донёс. Попробуй набросать свой собственный анализ исходя их своих реалий.

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

Можно делать это командой. Но лучше всего кросс-командной рабочей группой. Возьмите CTO, продакта, разрабов, QA, админов, безопасников. И крутого фасилитатора, который сумеет грамотно выстроить коммуникацию и задать правильные вопросы.

Всё — едем дальше.

Меряем Рыночную Гибкость

  1. TTM - Time To Market — можно делить по масштабу времени

    1. Фиксы - секьюрити, или надёжности: самый мелкий масштаб - минуты/часы и т.п.

    2. Фичи - тот самый TTM, который имеют в виду, когда говорят про TTM - выпуск новых версий уже существующих приложений - время от идеи до продакшна. Недели/спринты/кварталы и т.п.

    3. Компоненты продукта - приложения которые надо создать, или инструменты которые нужно внедрить. Недели/спринты/кварталы и т.п.

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

  2. DORA (4 Keys) - можно мерять характеристики TTM этой методой

    1. Подходит для кроссфункциональных команд

    2. Состоит из таких метрик:

      1. Deployment Frequency

      2. Lead Time for Changes

      3. Change Failure Rate

      4. Time To Restore

    3. Для функциональных команд не подходит, т.к. в большинстве случаев все ключевые результаты оказываются одновременно в области ответственности / экспертизы / полномочий сразу нескольких несвязанных команд: если одни поработали вот прям очень хорошо, на один конкретный результат, а другим это до лампочки - результат не изменился;

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

  3. Scalability:

    1. Принять больше работы: меряем Scaling Delay и имеющиеся ограничения (лимиты на ресурсы в клауде, или например розетки/порты/место в стойках)

    2. Выйти на новый рынок: меряемся TTM’ами из первого пункта

Меряем Косты

При выборе/разработке/внедрении каких-то новых решений, у нас есть примерно такие критерии:

  1. Цена создания

  2. Цена внедрения

  3. Цена владения

  1. Цена создания: смотрим на ФОТ и делаем сравнительный анализ решений

    1. берём параметры надёжности и безопасности как основу для формирования требований; Например, для решений хранящих данные:

      1. ресурсы и производительность: диски - объём, throughput, IOPS; Сеть - throughput, IOPS; CPU; RAM; Latency и TPS если есть понимание сколько нужно;

      2. отказоустойчивость: RTO & RPO как минимум. Replication Lag часто тоже неплохая метрика;

      3. безопасность: доставка апдейтов и ��отация секретов - выводим стоимость из требуемой частоты таких операций и затрачиваемых на это усилий;

    2. считаем стоимость создания решения для пары-тройки альтернатив: БД Aurora и самодельный кластер PostgreSQL в кубе, например;

  2. Цена внедрения: ФОТ, повторяемость, воспроизводимость

    1. договариваемся о том насколько часто нам нужно выкатывать наше решение;

    2. вспоминаем о частой ошибке: договориться о “редко”, или “один раз” и отсечь себе огромный кусок гибкости - в особенности в реагировании на инциденты,  восстановлении при сбоях и тестированиях гипотез;

    3. пример: договорились о “редко, или вовсе один раз” - умеем делать за полгода

      1. инцидент по секьюрити или надёжности, с компрометацией, или потерей данных: лежим, траблшутим. Траблшутинг - это всегда непредсказуемое время и трудозатраты без гарантии результата.

      2. тестирование бизнес-гипотез: можем дать решение один раз за полгода, а для тестирования гипотез хотелось бы раз в неделю за час;

      3. выход на новый рынок: та же история - у всех всё готово, но на аудит пойдём через полгода;

    4. пример: договорились о “как можно чаще” - умеем делать произвольное количество за час

      1. инцидент по секьюрити или надёжности: изолируем скомпрометированное, поднимаем новое, работаем; Дальше можно траблшутить, или делать форензику столько - сколько угодно, в том числе привлекая специализированные фирмы и органы;

      2. тестирование бизнес-гипотез: даём решение по мере необходимости, в рамках работы с рутиной, или вовсе даём автоматизированную ручку;

      3. выход на новый рынок: рутинное действие, которое никого не тормозит;

    5. передоговариваемся на менее рисковые цифры с учётом вышесказанного;

  3. Цена владения: чек от провайдера + апдейты + IRP/DRP как потребители ФОТ

    1. положим та же БД Aurora будет стоить нам $456/месяц, а эквивалентный инстанс EC2 - всего $68/м.;

    2. $397/м. экономии - ну здорово же, правда? Пускай админы на нём постгрю поднимут и го в прод, ну;

    3. Но только с RTO меньше минуты, RPO стремящимся к нулю и можно без хлеба;

    4. И доставкой обновлений по секьюрити/надёжности не реже раза в неделю;

    5. И с ротацией секретов;

    6. И поставкой в любой момент времени не дольше чем за 2 часа.

    7. За $397/месяц на всех наша команда админов осилит же, правда?

При управлении изменениями, есть ещё вот такой трюк: если изменение направлено на сокращение расходов, обсчитываем его по следующей схеме:

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

  2. считаем её среднюю стоимость человеко-часа:

    1. два разраба по $10k/мес.: 10000м/22д/8ч == 2*$56

    2. 1 QA по $6k: 6000м/22д/8ч == $34

    3. 2 админа по $7k: 7000м/22д/8ч == 2*$40

    4. тотал: (56+56+34+40+40)/5 == $194/час;

  3. считаем выгоду от изменения за год, пять, десять;

    1. ну путь, например, так: 1г - $1500; 5л - $7500; 10л - $15k;

  4. делим её на стоимость среднего человеко-часа работы;

  5. Получаем три интересных числа - вот тут внимание: максимальное количество человеко-часов нашей рабочей группы, которое мы можем позволить себе потратить на наше изменение, для того, чтобы оно вышло на окупаемость за год/пять/десять:

    1. 1г: 1500/194 == 7.7чч;

    2. 5л: 39чч;

    3. 10л: 77.3чч;

  6. Спрашиваем себя: 7.7 человеко-часов на всех - достаточны нашей рабочей группе, чтобы выполнить всю необходимую работу? а 39? а 77?

  7. Понимаем, что правдоподобная цифра лежит где-то посерединке между 39 и 77, а следовательно работа !начнёт! окупать себя, ну где-то лет - скажем -  через семь с половиной;

  8. Исходя из этого решаем стоит ли вообще делать эту работу.

Снимаем мерку с Operational Excellence

Термин, как я уже говорил, я позаимствовал у AWS. Но дальше наше с ними видение малость расходится, так что обладатели сертификатов — не расстраивайтесь, и не пролистывайте.

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

Напомню что мы будем пытаться посчитать:

  1. Рутины

  2. Управление изменениями (Change Management)

  3. Реагирование на инциденты (Incident Response)

  4. Восстановление в случае катастроф (Disaster Recovery)

В каких попугаях будем считать:

В каких-то ситуациях нам может быть удобно обсчитывать сложность работы в единицах времени. Особенно, когда речь идёт об IR/DR, а в каких-то время может быть вовсе не показательным, зато очень наглядно покажет себя метрика вроде «число действий, которые необходимо выполнить чтобы сделать работу».

Иногда полезной может быть метрика «число участников», или разбиение предыдущих двух по ролям/командам/отделам — например, при код-ревью наших изменений другой командой, или необходимости создавать заявки на доступы в саппорт и т.п. Ну или даже отдельно “число внешних связей” (или зависимостей от других команд).

Итого, для всего, что идёт ниже мы измеряем:

  1. время за которое мы делаем такие вещи;

  2. либо количество действий, которое нам необходимо предпринять, чтобы их выполнить;

  3. плюс, если нужно, число участников и число внешних связей.

Ну а дальше, когда мы видим, что именно нас не устраивает и почему — собираемся и брейнштормим как бы нам это упростить.

Что-то вроде:

- ок, посоны и посонессы — чтобы дать разрабу доступ к логам, нам приходится выполнить пять действий, два из которых — это ревью МР’ов в GitLab, выполняемое нашей же командой. Просто не тем человеком который непосредственно работает над этой таской. Давайте придумаем, как сделать чтобы действий стало на 4 меньше, а из участников остался только тот, кто делает таску?

- Кайф! А ещё лучше, чтобы мы вообще ничего для этого не делали — пусть разраб сам  запрашивает, а его менеджер в его команде сам тыкает где-нибудь аппрув — нормас, не?

- Уаааа, нормас! тоже нихачу робототь абизянай, хочу круто контрибьютить в бизнес, потому что мне по фану чувствовать свою ценность, а деньги это так приятный бонус —мне и без них есть где и на что жить;

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

Ну и так далее. Все же знают, как это бывает с живыми людьми, да ещё и на постсоветском пространстве, правда? ) “Токсота Совковая” (с)

Рутины

Всё что касается ежедневной мелкой работы, которую мы не планируем, но которая прилетает непредсказуемо и объём которой не зависит напрямую от нас самих.

  1. Запросы на доступы

  2. Ревью изменений - будь то прилетающих к нам извне, или же сделанных нашей командой

  3. Коммуникация в мессенджерах/тикетнице/почтах(omfg)

Дополни список тем, что актуально для тебя.

Тема снижения рутинной нагрузки много кем и где рассмотрена и без меня, так что просто просуммирую то, к чему человечество пришло в своём развитии:

  1. рутину можно просто не делать и иногда, для каких-то видов активностей это и правда рабочий способ;

  2. если не делать нельзя, то можно делегировать — пусть делают другие:

    1. например: если пишете манифесты для k8s за все продуктовые команды, то дайте им универсальный чарт или возможность писать манифесты самим - максимум ревьювьте МР’ы, а ещё лучше валидируйте это дело автоматом - линтеры и полиси-движки для куба вам в помощь;

    2. а если выдаёте доступы продуктовым командам, то дайте саппорту простую тычку «выдать/отозвать» — ещё и им жизнь упростите с отработкой наймов/увольнений;

  3. Ну и когда делегирование не помогает — рутину можно автоматизировать. Уже заметил, что тычку, линтеры и полиси-агенты из пункта выше можно, кстати и сюда пристроить? В итоге в нас выходит как-то так: “автоматизировали, для того чтобы делегировать”.

Вобщем да - эту тему только ленивый ещё не раскрыл. Разве что на заборах ещё не пишут что делать с рутиной (го флешмоб?).

А вот теперь небольшой десерт за счёт заведения: если поток рутины в вашей команде постоянный и достаточно значимый чтобы с ним считаться, то есть прекрасная практика, которая позволяет:

  1. гарантировать (в том числе другим командам) фиксированный объём ресурсов (пресловутых человеко-часов), выделенных в вашей команде на такие задачи;

  2. сделать более-менее предсказуемыми сроки взятия в работу рутинных задач / реагирования на обращения и т.п.;

  3. гарантировать вам самим как команде фиксированный обём ресурсов, выделенный на ту работу которую вы запланировали;

  4. гарантировать большей части вашей команды, что их запланированную работу никто не прервёт ни срочными задачами, ни вопросами в слаке;

Называется Routine Duties. Или по-нашему «Дежурства по текучке».

Простой пример:

  • команда из пяти человек;

  • на текучке один человек в день;

  • за пятидневную неделю у нас:

    • общая капасити 25 человеко-дней (200ч-часов);

    • 5 человеко-дней (или 40чч) выделено на рутину;

    • 20 человеко-дней (или 160чч часов) выделено на ту работу, которую мы запланировали;

    • у каждого из нас есть 4 дня в неделю на плановые задачи и один день на текучку;

    • когда ты не на текучке — тебя никто ничем не оторвёт от твоей работы;

Советы:

  1. договоритесь о том, что такое рутина, а что нет, применительно именно к вашей работе. Например:

    1. ревью МРов в GitLab;

    2. помощь продуктовым командам с вопросами в Slack;

    3. задачи в Jira, которые можно сделать максимум за 2 часа;

    4. раскидывание новых задач на текучку и “всё остальное” (триаж).

  2. договорённость вроде этой в придачу даст вам возможность анонсировать перфоманс вашей команды по рутинам: 8ч в день / 2 часа == до 4 тасок в день и 20 в неделю. Норм же, правда?

  3. в чатах типа Слака откажитесь от коммуникации в личке:

    1. сведите все внешние обращения к вашей команде в один публичный канал;

    2. общение внутри команды отделите от паблика в свой приватный канал;

  4. договоритесь как метить рутинные таски: в той же Jira можно выделить для них отдельный тип тикета и как вариант сделать для него отдельный воркфлоу;

  5. если с плановыми задачами вы работаете по скраму, то предыдущий пункт позволит вам положить рутину на Кан-Бан, да ещё и выкинуть её на отдельную доску, визуально разгрузив основную;

  6. по умолчанию классифицируйте все задачи извне как рутину;

  7. Всё: теперь дежурный по текучке смотрит только в рутинную доску, а все остальные только в скрамовую.

Change Management

Вообще, управление изменениями — отдельная большая тема (как и IR, как и DR), по которой стоит вот прям интересоваться и изучать «а как у других?».

Если у людей в статьях, конференциях и ютубах информации недостаточно, то можно советоваться с GPT’шкой и Gemini, они легко выдадут всю нужную базу.

В разделе про косты мы уже частично проговорили тему и полезные в ней метрики в разрезе денег и финансовой целесообразности.

А здесь, в разделе об Operational Excellence, давай сфокусируемся на том - как нам научиться измерять сложность изменений.

Определитесь что именно покрывает понятие управления изменениями в вашей работе.

  • Апдейты конфигов приложений на проде?;

  • Накатывание миграций на БД?;

  • Добавление нового микросервиса в продукт?;

  • Изменение реквизитов для доступа одних компонент к другим? Креды к БД для приложений и т.п.

  • Рутинные изменения в инфре: записи в DNS, правила в WAF, или сетевых фаерволах, правила на балансерах и ингрессах?;

  • Радикальные изменения в инфре, вроде миграции с одних решений на другие?. (Например, меняем в кубе игнрессы на гейтвеи, калико на силиум, хельм на нельм и т.п.)

Много чего ещё. Отдельно соберитесь командой, или даже продуктовой рабочей группой, составьте список. Распишите табличкой:

  1. участников: кто инициатор, кто делает, кто аппрувит, кто ревьюит и т.д.;

  2. частоту: если применимо - насколько часто возникает необходимость в конкретном виде изменений?

  3. количество участников / затраты времени / число выполняемых действий - то что актуальнее для конкретного процесса - не обязательно грести всё под одну гребёнку;

  4. внешние связи и зависимости между командами.

IRP

Интересная практика из опыта — выделять два плана реагирования на инциденты: секьюрити и всё остальное (надёжность по большей части). Разница — в составе участников и наборе действий. Деталей уже не упомню, но в отличие от надёжности, для секьюрити, помимо сугубо технической стороны, разница состоит в необходимости:

  1. вовремя и правильно (с минимизацией юридических рисков) анонсировать инцидент на пользователей/партнёров/регуляторов;

  2. коммуницировать с атакующей стороной, если в этом есть необходимость —  как в ситуациях с вымогательством, например;

  3. привлечь сторонних подрядчиков по технической части — для форензики и дальнейшей экспертизы в юридических процессах, следствии и суде;

  4. привлечь юристов и органы.

Эти истории, как правило, остаются за рамками компетенций/ответственности/полномочий технических команд, специалистов и руководителей, для которых предназначена статья в первую очередь.

Так или иначе, считаем мы с вами всё те же характеристики сложности работы: участников и время/число действий. Касательно характеристик времени, также стоит не забыть про MTTD&MTTR, которые мы уже прописывали в разделах выше. Наша цель влиять именно на эти показатели.

Из технического, в IRP нас могут интересовать:

  1. операции по восстановлению работоспособности сервисов: откаты неудачных деплоев, или миграций БД; переключ��ния на реплики и обратно, поднятие резервной инфры в DR сценариях вроде “pilot light”; восстановления из бэкапов и т.п.;

  2. при секьюрити инцидентах: действия по изоляции скомпрометированных компонент для целей прекращения атаки, или сохранения компонент для дальнейшей форензики и юридических процедур:

    1. compute инстансов, подсетей, VPC, целых проектов, или аккаунтов в облаке;

    2. пользовательских учёток сотрудников в сервисах;

    3. компьютеров и мобильных девайсов сотрудников;

  3. отдельно можно выделить кейсы инсайда — намеренного или нет:

    1. действия по оффбордингу сотрудника — отзыву всех доступов каких только можно — было бы здорово выполнять максимально просто и быстро;

    2. условный погромист Вася мог не получить рейз ЗП и решить сделать бяку;

    3. а мог качать гигазы вареза и теперь, сам не зная того, стать не единственным пользователем рабочего эйра.

    4. поэтому эйр нужно не просто изолировать, но по возможности ещё и сохранить для, опять же, дальнейших форензики и юридических процедур.

DRP

RTO & RPO — наше всё. Мы не ставим их самоцелью в текущем домене, но влиять всеми своими обжективами будем именно на них.

Если говорить о сценариях, где мы вынуждены поднимать всё заново, в том числе из резервных копий, то насколько нам легко выполнить нужные действия и насколько этих действий много, прямо влияет на метрику под названием Recovery Time. Это время, которое пройдёт от момента обнаружения сбоя, до восстановления работоспособности сервиса.

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

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

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

А ещё выделять некритичные функции в отдельные микросервисы и вытаскивать тяжёлые БД, очереди, кэши в выделенные кластеры.

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

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

Договоритесь также о том, для каких компонент целесообразнее иметь горячий резерв по сценарию Active-Active, или Warm Standby (по классификации принятой у AWS), а для каких сгодится  Pilot Light, или вовсе Backup/Restore.

Финалка по Operational Excellence

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

Но это иллюзия, от которой не останется и следа как только наше «сложно» превратится в чьё-то «долго», или «теперь уже поздно».

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

Всё померили, а дальше что?

Натягиваем SRE на глобус

А дальше всё как в старой сказке: SLI, SLO, Error Budgets и SLA. Только уже не про надёжность за вычетом всего, а вообще про всё что важно. Напомню: надёжность / безопасность / TTM и рыночная гибкость / Косты / Operational Excellence.

Если мы начинаем с нуля и уже договорились о том, какие бизнес-процессы для нас в приоритете и какие метрики (SLI) по ним мы собираемся трекать, то сейчас у нас возникла необходимость договориться о:

  1. SLO

  2. бюджетах ошибок

  3. и наших действиях при их превышении, или слишком стремительном расходовании.

Проще всего подойти к вопросу взяв исторические данные за несколько месяцев, например, 3 или 6, кому что актуальнее.

На выходе нам нужно получить два документа, фиксирующие наши договорённости:

  1. SLO: табличка, расписывающая по каждому БП (либо по системам/компонентам/областям применения, если конкретные метрики нет смысла применять к отдельным БП):

    1. метрики (SLI);

    2. способ - которым мы их получаем;

    3. значения, к которым мы стремимся (SLO);

    4. и как следствие — бюджеты ошибок: сколько проблем мы готовы позволить себе иметь прежде чем всё бросим и побежим работать над улучшением ситуации;

  2. Стратегия бюджетов ошибок — договорённости о том что мы делаем при их исчерпании, или ненормальной скорости сжигания:

    1. обязательно стоит расписать, кто и в каких ситуациях должен отложить свою плановую работу и направить силы на улучшение ситуации;

    2. а также кто может, но не обязан так поступать.

Стратегия и Burn Rate

SRE предназначен для принятия решений - причём не только стратегических, но в том числе и в моменте.

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

Например: если мы за неделю на половину исчерпали бюджет ошибок рассчитанный на 30 дней, то на дистанции в неделю-две-три, мы конечно можем видеть что пришло время взяться за ту, или иную метрику, поменять планы, изменить приоритеты и т.д.

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

Для этого введём такое понятие как Error Budget Burn Rate. 

Burn Rate - это скорость, с которой мы расходуем наш бюджет ошибок вот прямо сейчас.

Вот прямо как на спидометре: если мы едем минимально разрешённые 40 по автостраде - наверное мы доберёмся куда планировани сильно позже чем хотелось бы. А если 300 и не в Германии, то вероятно скоро намотаемся на столб, ну или как минимум отдадим денег.

Значения Burn Rate обычно тусуются где-то возле единицы.

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

При скорости 2 - он закончится вдвое быстрее чем нам хотелось бы и т.д.

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

Если утилизацию мы считаем за последние 30 дней, то Burn Rate стоит считать по данным за последний, например, час. Если очень хочется - можно считать за час и за сутки, например.

Пара примеров

Burn Rate вычисляется как отношение текущего уровня ошибок к максимально допустимому уровню ошибок по SLO.

Burn Rate = (Доля ошибок за период) / (Допустимая доля ошибок по SLO)

Если у нас SLO: «не более 2.56% ошибок», то:

burn_rate = (ошибки / все запросы) / 0.0256

Например, если за последний час:

  • Ошибок: 100

  • Всего запросов: 2000

  • Допустимый порог = 2.56% = 0.0256

тогда: burn_rate = (100 / 2000) / 0.0256 ≈ 1.95

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

И теперь мы можем строить принятие решений как в долгую, так и в моменте.

Пускай у нас есть простяцкая структура компании с одним продуктом и одной полностью кросс-функциональной продуктовой командой, которая включает в себя разрабов, QA, UX и админов.

Допустим по секьюрити мы договорились о:

  • SLI: время жизни уязвимостей в compute инстансах; измеряем сумму, скользящим окном в 30 дней;

  • SLO: TTL уязвимостей уровня critical

    • в 99% систем < 5 календарных дней;

    • в 90% < 2 рабочих дней;

  • Error Budget - как итог:

  • для 1% систем мы можем позволить себе исправить выявленные уязвимости уровня critical за время превышающее 5 календарных дней.

  • для 9% систем мы можем позволить себе исправить выявленные уязвимости уровня critical за время от 2х рабочих, до 5ти календарных дней.

Очевидно, что для того чтобы оставаться в рамках SLO нам нужно выкатывать обновления безопасности на наши compute инстансы за приемлемое время.

Если мы уже превысили SLO, либо видим что исчерпаем Error Budget раньше чем нужно, должны ли разработчики и QA прекратить работу над новым функционалом, до тех пор пока показатель не вернётся в норму? Похоже что нет, ведь это никак не поможет админам выкатить обновления.

Должна ли вся команда прекратить выпуск новых версий продукта пока показатель не вернётся в норму? Да тоже вроде не похоже.

А если секьюрити обновления поломают функционал продукта?

И вот у нас уже есть конфликт между риском для SLO по секьюрити и риском для SLO по надёжности.

Вполне вероятно, что для снижения рисков надёжности мы договорились тестировать продукт перед каждым обновлением. Тогда вероятно, чтобы вернуть SLI по секьюрити в норму, нам придётся отвлечь от работы по выпуску нового функционала как минимум наших QA. А если будут выявлены проблемы, то может ещё и разработчиков.

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

Управляем надёжностью

Тут и без нас сказано выше крыши — гуглокнижки отличный источник, они целиком про это.

Боюсь наповторяться, так что постараюсь просто кратко просуммировать то, что мы и так с вами знаем.

SLI

  1. стабильность (она же доступность): доля неуспешных транзакций (запросов, серий запросов) от их общего числа (Error Rate);

  2. своевременность (она же производительность):

    1. продолжительность (duration, latency) транзакции;

    2. предельное число транзакций в единицу времени (TPS/TPM/TPD/etc.);

  3. корректность:

    1. доля успешных, но не корректных транзакций (Failure Rate);

    2. время до обнаружения проблем (MTTD как в IRP);

    3. время до разрешения проблем (MTTR);

    4. методы обнаружения по типам проблем (например: утеря заказа - 100% обращение клиента; двойная доставка — 36% от клиента, 64% — пакетная валидация на нашей стороне);

    5. методы разрешения по типам проблем (например при утере заказа курьером в 96% случаев мы возвращаем деньги бонусами, в 3% деньгами, в 1% повторяем заказ за свой счёт);

  4. отказоустойчивость:

    1. RTO & RPO критических БП;

    2. RTO & RPO систем/компонент без привязки к БП;

    3. риски — о них поговорим отдельно;

  5. инциденты:

    1. количество, агрегируя по ущербу/severity;

    2. MTTD, агрегируя по ущербу/severity;

    3. MTTR, агрегируя по ущербу/severity.

SLO

  1. стабильность: просто предельная доля неуспехов, в процентах, по каждому БП;

  2. своевременность:

    1. latency: один-два-три значимых перцентиля, по каждому БП. Например: «при отправке формы регистрации пользователя 90% транзакций укладываются в 3мс, 99% — в 5мс»;

    2. TPS: число за время по каждому БП; Например: «акцепт заказа такси водителем: не менее 3800/мин. При большем количестве мы имеем право отдавать “сыстэм проблэм, попробуйте позже”»;

  3. корректность:

    1. Failure Rate: предельная доля (ex.: <7%);

    2. MTTD: значимые перцентили (90% двойных списаний по картам < 2 бизнес-дней; 99% < 1 недели);

    3. MTTR: значимые перцентили (90% < 1 часа; 99% < 4ч.);

    4. методы обнаружения: предельная доля

      1. например: 85% ошибочных транзакций выявляются автоматизированно

      2. отсюда выходит и вариант бюджета ошибок: <=25% выявлений через обращения клиентов в службу поддержки;

    5. методы разрешения: предельная доля

      1. тут можно отплясать от бюджета ошибок;

      2. например: не более N% кейсов разрешаются финансовой компенсацией клиенту, не более K% бонусами и фантиками;

      3. ну или так: не более X% квартальной выручки уходит на финансовые компенсации, не более Y% себестоимости на компенсационные фантики и бонусы;

  4. отказоустойчивость:

    1. RTO & RPO - единицы времени по критическим БП (пользовательские регистрации: RTO < 4ч, RPO < 7дн.; заказы такси: RTO < 10мин, RPO < 1мин.);

    2. RTO & RPO систем/компонент без привязки к БП (БД заказов: <1мин & ~0, приложение-монолит: <10мин & 0);

  5. инциденты:

    1. предельное количество, агрегируя по ущербу/severity;

    2. предельный MTTD: значимые перцентили, агрегируя по ущербу/severity;

    3. предельный MTTR: значимые перцентили, агрегируя по ущербу/severity.

Управляем безопасностью

Инциденты

  • SLI:

    • Количество с разбивкой по ущербу/severity;

    • MTTD;

    • MTTR;

  • SLO и Error Budget:

    • Предельная доля по ущербу/severity;

    • MTTD: значимые перцентили по ущербу/severity (например: 90% detected in <=1min, 95% detected in <=5min, 99% detected in <=1hr);

    • MTTR: значимые перцентили по ущербу/severity.

Договорённость о том, что такое низкий/средний/высокий ущерб и как мы считаем severity - необходимо выработать и зафиксировать на берегу.

Уязвимости

SLI:

  1. количество и время жизни (TTL) самих уязвимостей/мисконфигураций, с агрегацией по severity и источнику (например: “low / medium / high / critical” X “исходный код / его зависимости / пакеты в Docker-образах”);

  2. или, если удобно: количество систем/узлов подверженных выявленным уязвимостям/мисконфигурациям и TTL последних, также с агрегацией по severity и источнику (например: “low / medium / high / critical” X “compute / cloud resources / K8s”).

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

Тогда как к TTL уязвимостей и мисконфигураций на серверах, compute-инстансах, в K8s кластерах, проектах GCP, или аккаунтах AWS будет полезно добавить ещё и количество подверженных им систем.

SLO:

значимые перцентили из TTL, раскиданные по severity и источнику выглядят вроде разумно. Например: для critical на compute-инстансах - на 90% узлов TTL < 2 дней, на 99% TTL < 5 дней. Или: 90% high в коде живут < 1 спринта, 99% < 4 спринтов.

Рулим рыночной гибкостью

TTM

SLI — в еденицах времени, SLO — в имеющих смысл перцентилях. И то и другое, с агрегацией по типу изменений: фиксы/фичи - как минимум.

Например: 

  • 90% фиксов выкатываются не дольше чем за 2 дня, 99% - укладываются в неделю;

  • 90% фич проходят путь от идеи до пользователя не больше чем за 1,5 спринта, 99% - максимум за 3 спринта.

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

Например, если взять за SLI метрику “Deployment Frequency”: 

Мы можем конечно сказать что наш SLO будет выглядеть как “>5 успешных деплоев в прод в неделю; >=95% недель укладываются в метрику”. Но куда это нас приведёт? К дроблению релизов на мелкие кусочки? Расскажи в каментах что думаешь по этому поводу и как можно было бы сформулировать реально полезный SLO по такой метрике.

Lead Time for Changes: P50 ≤ 24ч., P95 ≤ 3дн. - не начнём ли мы откладывать коммит исходного кода до последнего, чтобы уложиться в обжектив?

Ну и так далее: если вот прям интересно - не стесняйся придумать свои варианты вредных и полезных SLO для “Change Failure Rate”, “Time To Restore” и поделиться в каментах.

Масштабируемость

способность “принять больше работы” когда надо

Scaling Delay: 95% подов приложения в K8s (ну или EC2 инстансов в EC2 ASG, ну или серверов в стойках - кому что) включаются в работу не дольше чем через 60 секунд с момента срабатывания автоскейлера (привет Java); 99% - не дольше чем за 180c.

ограничения (лимиты на ресурсы в клауде, или например розетки/порты/место в стойках; наличие в проекте немасштабируемых компонент и их лимиты производительности и т.д.)

Выйти на новый рынок

про TTM’ы мы уже поговорили - тут нас интересуют те из них, которые про выкатку новых фич, новых компонент продукта, новых продуктов и поднятие нового экземпляра продукта в новом регионе.

Приглядываем за костами

SLI

Считаем сумму из “Цена создания” + “Цена внедрения” + “Цена владения” и за SLI берём не деньги (сюрпрайз), а сроки:

  1. сроки поставки решений

    1. первичной (включая инженерию и рисёрч)

    2. и регулярной (когда всё умеем - только штампуй)

  2. и их окупаемость по сумме стоимости:  трудозатрат на инженерию, трудозатрат на внедрение, поставку и стоимости ресурсов (тот самый чек от AWS/GCP, или ДЦ, который в нашей постсовковой традиции принято ошибочно принимать за полную стоимость владения)

SLO

навскидку, могли бы выглядеть п��имерно так:

  1. 95% технических решений поставляются первично не дольше чем за 1 спринт, при соблюдении SLO по надёжности и безопасности;

  2. 99% - не дольше чем за 1.5 месяца;

  3. 95% регулярных поставок - не дольше 2ч., 99% - не дольше 1дн.;

  4. 95% окупаются не дольше 3мес.; 99% - не дольше полугода.

Здесь можно много всего придумать. Накидай идей в каменты.

Operational Excellence

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

Так что если кажется что тут я иногда повторяюсь - не кажется - так и задумано.

Что там у нас было?

  • Удавы:

    • Рутины,

    • Change Management,

    • Incident Response

    • и Disaster Recovery.

  • Попугаи:

    • Единицы времени,

    • число действий,

    • число участников,

    • число внешних связей (зависимостей).

MTTD&MTTR для IRP и DR мы в этом домене не рассматриваем, но по факту, все метрики тут - влияют именно на них.

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

Ок, погнали -  сейчас вместе немножко думаем в примерах и потом самостоятельно экстраполируем навык под свои нужды со своей командой:

Пример 1

Возьмёмся с порога за первое попавшееся: Рутины и Единицы Времени. Что бы нам тут померять, чтобы ответить на вопрос “насколько нам легко делать нашу работу”?

Помнишь я предлагал считать за рутину внешние таски, которые выглядят как “работа на 2 часа максимум”? И мы из этого могли выдать наружу метрику для SLA вида “до 4х тасок за день”.

Мы можем из этого вывести SLO вида “задача такого-то типа требует не более 2х часов на выполнение”. Именно “требует не более…”, а не “выполняется не дольше”.

Почему? Потому что характеристика, которая нас тут интересует - это не перфоманс сотрудников на текучке, а именно “насколько сложно нам делать вот такую вот работу”.

И обжектив мы принимаем не для того, чтобы условному Васе запретить бегать в курилку со словами “пока 4 таски за день не сделал - домой не ушёл”, а для того, чтобы собраться всем вместе и побрейнштормить “как нам ускорить вот такие-то задачи, чтобы они укладывались в 2 часа”.

Мы тут не стремимся закрыть KPI для perf. review. Наша задача - научиться “делать просто, потому что сложно сделать любой дурак сумеет”.

Пример 2

Ну пусть будет IRP и число внешних связей - я просто от балды дёрнул.

Если для того чтобы поднять какую-то систему из бэкапа нам нужно прогнать MR в гитлабе через пяток аппрувов в трёх командах, только после этого увидеть что оно не взлетело, потому что где-то в коде пропущена запятая (пятью аппруверами? Да легко вообще!), пушнуть односимвольное исправление и пойти на новый круг из пяти аппрувов - наверное это будет чуточку дольше, чем если один инженер просто сделает всю работу сам, правда?

Допустим у нас есть процесс реагирования на инциденты “поднять БД монолита из бэкапа”. В качестве SLO здесь можно принять что-нибудь вроде “требуемое число инженеров < 2,” и “требуемое число обращений к другим командам == 0”.

Итого

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

Кидай в каменты свои варианты из опыта, или просто из головы - вот что откликнулось.

Риски

Выношу за скобки как и обещал. Риски мы меряем и трекаем как минимум для:

  1. надёжности;

  2. безопасности;

  3. рыночной гибкости.

Опционально для костов. Может быть также и для Operational Excellence. Ситуативно. Когда в этом есть смысл. Например, если какое-то важное решение не получается выбрать, или просто отделаться от сомнений.

Если в частном случае это оказывается удобно, чтобы видеть их взаимное влияние между разными доменами и картину в целом — почему нет? Хотя бы самые очевидные и значимые.

Например, частая практика, многим (до боли?) знакомая, минимизация рисков надёжности, или безопасности путём внедрения новых, в другом домене.

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

А в картине рисков это может в итоге выглядеть так, что снижая, для надёжности нашего сервиса, риск «человеческой ошибки» мы тем самым увеличиваем, или вовсе создаём там, где его не было, новый риск «не суметь внести нужные изменения вовремя» с ущербами сразу для:

  1. той же самой надёжности (особенно когда речь идёт о критической ситуации);

  2. рыночной гибкости нашего продукта;

  3. стоимости вносимых изменений;

  4. и даже для безопасности - в ситуациях когда мы не в состоянии что-то оперативно пофиксить.

SLI: количество рисков с агрегацией по домену и severity.

Например: “низкие/средние/высокие/фатальные” X “надёжность/безопасность/гибкость/косты”

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

Можно также добавить TTL, чтобы более детально целеполагаться и, например, среди рисков с одинаковым уровнем приоритезировать те, что имеют более продолжительное время жизни.

Ещё можно строить оценку рисков отталкиваясь от вероятности на определённой временной дистанции. Например использовать коэффициент повышения вероятности в проекции на месяц/квартал/год/5/10.

Например: какова вероятность отказа us-east-1 в AWS в ближайшие 30 дней? 5 лет? 10?

Можно попробовать оттолкнуться от исторических данных. По опыту - что в GCP, что у AWS хоть один регион, да ляжет раз в пару лет. Можно просто договориться о предположительных синтетических попугаях вида «чем дольше — тем хуже».

Для нас с тобой точные (или даже приблизительные) цифры не особо-то и важны: предсказывать будущее — дело неблагодарное. Нам важна возможность учесть рост вероятности с течением времени и использовать этот фактор, чтобы нагляднее раскладывать наши цели и планы на календарь.

Небольшой пример напоследок

Рассмотрим вот такой вот БП для разнообразия: "Выставление ордера на бирже".

SLO: "95% успешных транзакций выполняются не дольше 140мс, 99% не дольше 500мс".

SLO карточка для Confluence/GitLab Wiki

Бизнес-процесс

Выставление ордера на бирже (Place Order)
 Что считаем транзакцией: запрос на выставление ордера, который дошёл до биржи и получил подтверждение приёма (ACK) или финальный отказ (REJECT).

SLI

Latency (end-to-end): время от момента, когда API/гейтвей принял запрос на ордер, до момента, когда получен ответ биржи (ACK/REJECT) и он зафиксирован/отдан обратно вызывающей стороне.

  • P95 Latency ≤ 140 ms

  • P99 Latency ≤ 500 ms

SLO

В течение скользящего окна 30 дней:

  • 95% успешных транзакций укладываются в ≤ 140 ms

  • 99% успешных транзакций укладываются в ≤ 500 ms

Error Budget

Перцентили это не «процент ошибок», но бюджет можно считать как допустимую долю “медленных транзакций”.

В окне 30 дней пусть N_success = число успешных транзакций.

Бюджет P95

Чтобы P95 ≤ 140ms, не более 5% успешных транзакций могут быть дольше 140ms:

  • EB95_slow = 0.05 × N_success (шт. “медленных успешных”)

Бюджет P99

Чтобы P99 ≤ 500ms, не более 1% успешных транзакций могут быть дольше 500ms:

  • EB99_very_slow = 0.01 × N_success (шт. “очень медленных успешных”)

Практичный момент: P99 обычно «больнее» и быстрее сигналит о деградации хвоста. Поэтому в стратегии ниже я бы предложил триггеры в первую очередь на >500ms.

Архитектура измерения latency (без шаманства)

Для БП «Выставление ордера» нам важно видеть хвост, а не среднюю температуру по бирже.

Режем end-to-end на 4 сегмента

Client => Gateway => Order Service => Outbound (FIX / REST / TCP) 

                                      => Exchange

                                      <= Response

Сегменты

  1. edge_latency
    Приём запроса, auth, routing, rate limit

  2. app_latency
    Бизнес-логика, валидации, риск-чеки, сериализация

  3. outbound_latency
    Сеть + клиент + ожидание ответа биржи

  4. exchange_latency (если биржа отдаёт timestamp)
    Полезно, но опционально

Почему так: P99 почти всегда живёт либо в outbound, либо в app (GC/locks/проблемы масштабирования). Сегментация latency даст нам лютейший буст к скорости анализа и купирования  критической ситуации.

Алертинг (минимум, который реально работает)

Warning: хвост растёт

histogram_quantile(0.99, ...)

> 500

for 3m

High: жжём бюджет

EB99_burn_rate > 2

for 5m

Critical

EB99_burn_rate > 5

for 2m

Политика Error Budget: что делаем, когда горит

Триггеры (пример)

  • Warning: за последние 24 часа израсходовано ≥ 25% EB99

  • High: за последние 24 часа израсходовано ≥ 50% EB99

  • Critical: EB99 исчерпан (или прогноз исчерпания в ближайшие 7 дней)

Действия

Warning

  • включаем ежедневный разбор “tail latency”: топ-N причин (по тэгам: биржа/сеть/GC/локи/DB/кеш/серилизация)

  • ограничиваем “рискованные” релизы: только low-risk, feature flags, без миграций

High

  • замораживаем релизы, которые могут ухудшать latency хвоста

  • выделяем кросс-функциональную группу (SRE/Dev/QA/Net) на 2–3 дня: цель вернуть EB99 в зелёную зону

  • включаем усиленный мониторинг: перцентильные алерты + корреляция по рынкам/биржам/региону

Critical

  • фокус команды: только работы, уменьшающие latency (или изоляция биржи/канала, деградация функционала, переключение маршрута)

  • постмортем обязателен, с конкретным “исправили/не исправили/почему”

"Границы измерения" - чтобы метрика была честной

Чтобы SLO не превратился в спор “а где меряем?”, фиксируем:

  • start: запрос принят на входе (edge/gateway)

  • end: получен ответ биржи + запись события “order_accepted” в event log/шину (или хотя бы подтверждение отправки клиенту, если event log не синхронный)

  • считаем только успешные транзакции, но добавляем рядом “охранника” в виде SLO по доле успешных транзакций. Чтобы не получить ситуацию, где мы улучшили latency снизив долю успехов.

Как превратить цифры в работу, а работу — в результат

Итак, мы научились измерять. Потом договорились, какие значения считаем приемлемыми (SLO) и сколько можем позволить себе облажаться (Error Budget).

Логичный вопрос: а что дальше? Где тут цели, планы и та самая “работа на квартал”?

Вот здесь и появляется OKR. Не как модное слово из книжки, а как механизм перевода SRE-языка на человеческий.

Зачем вообще OKR, если есть SLO и Error Budget?

Потому что:

  • SLO отвечает на вопрос “что для нас нормально”;

  • Error Budget — “когда нужно перестать делать вид, что всё нормально”;

  • Error Budget Policy — “что мы делаем в моменте”

  • но ни то, ни другое, ни третье не отвечает на вопрос “что именно мы собираемся улучшать в долгосрочной перспективе”.

Если этого не сделать явно, происходит классика:

  • SLO соблюдаются => “ну значит всё ок, ничего не трогаем”;

  • SLO горят => “всем срочно чинить всё подряд”.

OKR нужен ровно для того, чтобы:

  • выбрать фокус улучшений;

  • отделить развитие от пожаротушения;

  • и связать техническую работу с рисками и бизнес-целями, а не с абстрактным “улучшением надёжности”.

Главное правило (очень важно)

SLO — это не цель.
Цель — это изменение системы, которое делает соблюдение SLO дешевле, стабильнее и предсказуемее.

Если Objective звучит как: “Соблюдать SLO по latency” — это не OKR, это тавтология.

Как рождается OKR из SLO и Error Budget

Процесс выглядит так:

  1. Смотрим на SLO
     Где мы:

    • стабильно близко к границе?

    • регулярно жжём Error Budget?

    • держимся “на честном слове и ручных костылях”?

  2. Формулируем проблему в терминах риска, а не технологий
    Не “у нас медленно”, а:

    • “мы теряем контроль над хвостом latency в пиковые часы”;

    • “одна биржа съедает 70% EB99”;

    • “каждый security-релиз рискует снести P99”.

  3. Objective = снижение конкретного риска, а не внедрение инструмента
    Objective всегда отвечает на вопрос: “Что станет менее опасным для бизнеса, если мы это сделаем?”

  4. Key Results берём из метрик и бюджетов
     Не “сделать”, а “изменить измеримое поведение системы”.

Пример: как это выглядит в реальности

Допустим, по БП «Выставление ордера» мы видим:

  • SLO по P99 = 500 ms;

  • EB99 сгорает каждый раз при пиках;

  • корень проблем — outbound + конкретная биржа.

Тогда OKR выглядит не так:

❌ Objective: “Оптимизировать latency”

А вот так:

✅ Objective: Сделать хвост latency выставления ордера предсказуемым и управляемым под нагрузкой.

Key Results:

  • KR1: EB99 исчерпывается не чаще 1 раза за квартал;

  • KR2: доля транзакций > 500 ms снижена на 30% от baseline;

  • KR3: для 100% деградаций P99 есть установленная и подтверждённая причина.

Обрати внимание: ни слова про Kubernetes, GC, FIX или TLS. Только риск и наблюдаемое поведение системы.

А планы где?

Вот теперь — всё чес��но.

Планы (инициативы, эпики, задачи):

  • не часть OKR;

  • не являются Key Results;

  • и могут меняться хоть каждую неделю.

Они отвечают на другой вопрос: “Что мы попробуем сделать, чтобы эти KR стали достижимыми?”

Пример:

  • разрезать latency по сегментам;

  • изменить retry policy;

  • вынести security-контроль из hot-path;

  • изменить архитектуру outbound-пула.

Если план не двигает ни один KR — это либо хобби, либо технический туризм.

Как это помогает в жизни (а не в презентациях)

  • SLO страница - это контракт с бизнесом; SLO говорит бизнесу: “вот границы нормы”

  • Error Budget говорит: “вот когда пора тормозить”

  • Error Budget Policy говорит: “если надо затормозить, отпусти газ, подожми тормоз; если надо экстренно затормозить - зажми тормоз до упора - у тебя АБС есть”

  • OKR - фокус квартала. Он говорит команде: “вот куда мы целимся в ближайшие три месяца”

В результате:

  • появляется аргументированное “почему именно этим занимаемся”;

  • исчезает хаос из несвязанных улучшений;

  • техническая работа начинает выглядеть как управление рисками, а не как обслуживание инфраструктуры.

Короткий итог

Мы прошли путь:
метрики => SLO => Error Budgets => Error Budget Policy => OKR => планы

И это не бюрократия, если помнить одну простую мысль:

Мы меряем не ради цифр.
Мы меряем, чтобы принимать решения - что делать, что важнее и чего не делать вовсе.

Типовые анти-паттерны OKR “по-SRE”

или как случайно всё испортить, имея хорошие метрики

OKR задумывался как инструмент фокуса и выбора. В инженерной среде он часто превращается либо в KPI под другим названием, либо в витрину для технического эго. Ниже — самые частые способы выстрелить себе в ногу.

Анти-паттерн №1

Objective = “Соблюдать SLO”

“Objective: соблюдать SLO по latency”
 “KR: P99 ≤ 500ms”

Почему плохо:
SLO — это граница нормы, а не направление движения.
Если Objective совпадает с SLO, то:

  • при выполнении SLO цель формально достигнута безо всякой работы;

  • при нарушении SLO OKR превращается в пожарную инструкцию.

Как правильно:
Objective должен описывать снижение риска или изменение свойств системы.

Пример:

  • ❌ “Соблюдать SLO по P99”

  • ✅ “Сделать хвост latency управляемым под пиковыми нагрузками”

Анти-паттерн №2

Key Results как список задач

  1. KR1: внедрить distributed tracing

  2. KR2: переписать outbound-клиент

  3. KR3: оптимизировать GC

Почему плохо:
Это не результаты, а намерения.
Можно всё внедрить, переписать и оптимизировать — и при этом:

  • P99 не изменится;

  • Error Budget продолжит гореть;

  • риск останется тем же.

Как правильно:
KR должны быть измеримыми эффектами, а не действиями.

Пример:

  • ❌ “Внедрить трейсинг”

  • ✅ “100% деградаций P99 имеют установленную причину ≤ 30 минут”

Анти-паттерн №3

KR без привязки к Error Budget

“KR: снизить P99 на 10%”

Почему плохо:
Без контекста Error Budget:

  • непонятно, важно ли это вообще;

  • неясно, где приоритет относительно других рисков;

  • невозможно объяснить бизнесу, зачем именно это улучшение.

Как правильно:
KR должны быть связаны с частотой, скоростью или масштабом сжигания бюджета ошибок.

Пример:

  • ❌ “Снизить P99”

  • ✅ “EB99 исчерпывается не чаще 1 раза за квартал”

Анти-паттерн №4

OKR как KPI для перформанс-ревью

“Команда не выполнила KR — значит плохо поработала”

Почему плохо:
Как только OKR становится персональной оценкой:

  • команды начинают оптимизировать цифры, а не систему;

  • хвосты прячут, метрики фильтруют, инциденты переименовывают;

  • риски уходят в тень, где и взрываются.

Как правильно:
OKR — это инструмент обучения системы, а не оценки людей.

Формула здоро��ого подхода:

OKR не выполнен → мы узнали, что система устроена не так, как думали.

Анти-паттерн №5

Смешивание доменов в одном Objective

“Objective: улучшить надёжность, безопасность и снизить косты”

Почему плохо:
Каждый домен тянет систему в свою сторону:

  • безопасность часто увеличивает latency и TTM;

  • снижение костов может бить по отказоустойчивости;

  • надёжность тоже конфликтует и с TTM и со стоимостью.

В итоге:

  • Objective неконтролируем;

  • приоритеты начинают меняться по настроению.

Как правильно:
Один Objective — один доминирующий риск.
Конфликты между доменами выносятся в обсуждение, а не замалчиваются.

Анти-паттерн №6

OKR без границ применимости

“Снизить latency системы”

Какой системы? Где? Для кого? Частая история: OKR вроде бы выполнен, но:

  • критичный БП всё ещё горит;

  • улучшения ушли в неважные места.

Как правильно:
OKR всегда привязывается:

  • к конкретному бизнес-процессу;

  • или к конкретному классу рисков.

Пример:

  • ❌ “Снизить latency”

  • ✅ “Снизить tail latency БП ‘Выставление ордера’ под пиковыми нагрузками”

Анти-паттерн №7

Слишком много OKR

“У нас 5 Objectives и по 4 KR на каждый”

Почему плохо:
Это не фокус, а расписание перегруза.
Команда не выбирает — команда тонет.

Как правильно:
Для технических команд почти всегда работает:

  • 1–2 Objective на квартал;

  • по 2–3 KR на каждый.

Если хочется больше — значит, приоритезации не произошло.

Анти-паттерн №8

OKR без права сказать “мы это не делаем”

Если любой запрос сверху можно обосновать как “важный”, а OKR не помогает от него отбиться — это не OKR.

Здоровый OKR даёт фразу:

“Это хорошая идея, но она не двигает ни один из наших KR в этом квартале.”

И это нормальный, профессиональный ответ, а не саботаж.

Короткий чек-лист здорового OKR “по-SRE”

Перед тем как зафиксировать OKR, спроси себя:

  • Objective описывает риск, а не метрику?

  • KR измеряют поведение системы, а не активность людей?

  • Есть связь с SLO и Error Budget?

  • Можно ли честно не выполнить OKR и не искать виноватых?

  • Помогает ли этот OKR отказаться от лишней работы?

Если на все “да” — поздравляю, ты используешь OKR как инженер, а не как менеджер по отчётам.

Зачем это всё, что делать завтра, и как не превратить жизнь в бюрократию

Если ты не приносишь выручку напрямую, у тебя всё равно есть P&L. Просто он записан не в «прибыло денег», а в «сколько денег мы не потеряли» и «как быстро мы способны заработать завтра».
Твоя ценность обычно сидит в четырёх местах:

  1. Надёжность: бизнес-процесс происходит вовремя и правильно.

  2. Безопасность: нас не ломают, деньги и данные остаются при нас, комплаенс не превращается в похоронный марш.

  3. Гибкость: мы успеваем за рынком и спросом.

  4. Косты: мы покупаем результат, а не дорогое чувство контроля.
    И всё это держится на пятом ките, который никто не любит, но без него всё тонет: Operational Excellence.

Главная мысль

SRE не про «аптайм». SRE это способ договариваться (о приемлемом), измерять (то, что важно), и выбирать действия (когда важное поехало).
Если растянуть этот подход на все домены, получаем универсальный инструмент: мы меряем не работу, а риск и способность бизнеса двигаться.

Минимальный план на квартал, чтобы оно заработало

Шаг 1. Выберите “топ-3” бизнес-процессов

Не всё в мире, а три штуки, которые реально делают кассу. Без этого любые метрики превращаются в красивый шум.

Шаг 2. Для каждого процесса выпишите 5 доменов и по 1–2 метрики

Не пытайся «покрыть всё». Твоя цель: запустить цикл, а не построить кафедру метрикологии (хотел было шуткануть про церковь метрик, но “Церковь Метрик” клёвые и полезные - не надо их обижать).

Пример “скелета”:

  • Надёжность: error rate + latency + инциденты (MTTD/MTTR)

  • Безопасность: TTL критичных уязвимостей + реестр рисков на минималках

  • Гибкость: TTM (идея -> прод / хотфиксы) или DORA (если вы полностью кросс-функциональны)

  • Косты: стоимость владения + окупаемость изменений

  • OpEx: время/число действий на типовую рутину, change, IR/DR

Шаг 3. Договоритесь о SLO и Error Budgets

Исторические данные за 3–6 месяцев, потом простая табличка:
SLI => SLO => Error Budget => что делаем, когда бюджет горит.

Самое важное тут:
кто обязан замедлиться, а кто может помочь, если метрика горит.
Иначе мы упрёмся в вечную магию: «у нас всё важно одновременно».

Шаг 4. Введите одно правило анти-бюрократии

Если метрика не помогает принять решение, она не метрика, а сувенир. Каждой метрике нужен вопрос вида: “Если значение стало хуже, какие 1–3 действия мы делаем?”

Как выглядит “успех” этой системы

Успех не в том, что все графики зелёные. А в том, что:

  • вы можете называть риски словами, а не эмоциями;

  • вы умеете сравнивать инициативы (что важнее и почему);

  • вы перестаёте «делать всё подряд» и начинаете сжигать риски осознанно;

  • у вас появляется честный нарратив для бизнеса: “Мы сделали A, поэтому вероятность B снизилась, а ущерб C стал меньше”

И последнее: про чувство собственной ценности

Ценность технаря, который “не приносит выручку”, в том, что он делает бизнес живучим, управляемым и быстрым.

Ты продаёшь не аптайм и не кубер. Ты продаёшь возможность бизнесу не умереть глупо и успевать умно.