Градиент проблем

Запас прочности чего-угодно не тратится моментально. Обычно.
Лучше иметь под рукой шкалу мониторинга и оценки, чтобы не было нежданчиков.

Не бывает (чаще всего) так, что всё было зашибись и лучезарно, а потом опа! — и мы в кромешной заднице. Обычно у систем, людей, процессов, явлений есть запас прочности, далее копится «наработка на отказ».

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

Логично предположить, что в ситуации «ой, сдохло?» набор проблем тоже копился постепенно. Просто вы почему-то этого не заметили.

А надо, чтобы заметили.

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

Для нас это означает также то, что если «ничего не происходит», любая система все равно будет деградировать и разрушаться. Потому что вокруг микромира стазиса все равно меняется вся остальная вселенная. Иногда довольно долго; ну ничего, мироздание умеет ждать, бгг.

Есть еще талебовская «антихрупкость», если помните.

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

— ремонт (по внутренним причинам что-то сдохло или деградировало)
— адаптация (внешний мир поменялся, и теперь в системе что-то не работает)

Кто не адаптируется, тот сдохнет, это нам Дарвин говорил. Кто не ремонтируется — уже сдох; тут регенерация еще до Дарвина подсуетилась. Необходимость — налицо.

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

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

Первая мысль, которую надо вынести — это иметь метрику «усталости». Она обычно коррелирует с этапами деградации и их проявлениями выше, но не всегда. Бинарный подход «жило, жило, а потом умерло» это бинарное упрощение, которое выйдет вам боком именно из-за своего упрощения; дихотомия, в которую вы тупо закопали саму проблему.

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

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

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

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

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

Еще помним о том, что: внутри систем и процессов, предоставленных самим себе, неизбежно и неумолимо копится бардак. Внутренняя энтропия. Остаются непроработанные штуки, костыли, изолента, огрызки устаревшего, легаси и рыбные кости по углам. Искать и разгребать дорого; но копиться все равно будет. Рано или поздно имеет все шансы накопиться до критической массы, по верхней шкале. Deal with it.

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

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

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

Модель угроз некоторые понимают слишком буквально; в данном случае вас интересуют, в первую очередь, самые статистически значимые. Риск того, что у вас ляжет вся инфраструктура разом, или упадет самолет со всей командой в полном составе — он, конечно, очень дорогой. Но риски косяков отдельных людей, отказов оборудования или bus factor — к вам гораздо ближе статистически.

Мы смотрим здесь только на статистику потому, что наша задача (в этом контексте) — не предотвратить, а померить, оценить, предсказать и обработать. Т.е вопрос даже не в том, ляжет ли у вас вся инфра разом, а в том, что вы сделали, чтобы узнать об этом вовремя и заранее.

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

Примеры, «где не надо», возможно навскидку:

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

С последним интересно. Это отчасти повторяет подход «сломается — возьмем с полки новое». Если где-то можно поступить подобным образом, это перспективно и имеет, возможно, операционные плюсы. Например, для систем доставки данных некритическая возможность полного отказа — «сдох кеш, возьми с мастера» — это достаточно здорово, потому что вам становится искренне пофиг, потеряли и потеряли, никто даже и не заметит (пока берем с полки и тащим замену). Вы переходите от бинарности и зависимости к циферке и проценту покрытия. На вышестоящем уровне пока не сдохло, условно, 50% парка, это не проблема — это расходы.

К процессам и людям точно так же относится, сорян.

Обратите внимание, в заметке нет слова «технический долг», хотя очевидно, что с градиентом проблем он напрямую связан. Пока достаточно того, что аналогию проведете самостоятельно. Подход тот же:

— оценка и метрика,
— механизм восстановления,
— слабые места,
— периметр эксплуатации.

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