На обеде с коллегой обсуждали годовые цели для нашего департамента (их выполнение прямо влияет на бонус).

Из года в год цели выставляются практически одинаковые. Две основные - uptime (в многочисленных девятках) и список “фич”, которые мы должны “доставить”.
Не смотря на то, что цели выставляются по модели S.M.A.R.T., они не всегда таковыми являются. Я не хочу вдаваться в подробности внутренней кухни - просто приметим, что достижение обеих целей (uptime и feature delivery) одновременно практически невозможно, либо требует титанического труда всех департаментов (бизнесовых в том числе).

На выходе имеем, что наш департамент либо “доставит” нужное количество “фич” (которые в течение года могут, конечно же, меняться, ведь у нас “Agile”), либо бросит бОльшую часть сил на добавление лишней девятки в наш uptime.
В то время, как что downtime, что разработанный функционал лишь косвенно влияют на корпоративные цели (продать товара побольше, потратить денег поменьше), а новые “фичи” носят больше внутренний характер и очень редко удовлетворяют “хотелки” больших клиентов.
Downtime же практически не влияет на наш business continuity: можно было бы приплести его к удовлетворенности клиентов, но они гораздо больше расстраиваются, вися на телефоне с техподдержкой, нежели когда наш money printer отрабатывает транзакции с часовой задержкой. Ну а бизнес-системы созданы таким образом, что их падение на недлительный срок никак не влияет на доход фирмы.

О чем нам стоит волноваться совсем не uptime, но RPO (recovery point objective). “Лежащая” база - нестрашно. “Лежащая” база, потерявшая транзакций на сутки - вот это это уже проблема. Но таких целей нам не ставят.

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