9.0

Смотреть на английском

9.0 Введение к части 9: Эксплуатация, надёжность и наблюдаемость

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

Для больших команд эти заботы перестают быть фоновой деятельностью и становятся самостоятельной системой. Современная платформа охватывает сотни сервисов, многие команды, несколько регионов и сторонние зависимости, и ни один человек не держит всё это в голове. Масштаб повышает и ценность надёжности, и цену ошибки. Час простоя оборачивается потерянной выручкой и подорванным доверием. Одно расплывчатое оповещение становится тысячами вызовов. Несколько пунктов облачных потерь становятся миллионами долларов. Эксплуатации в таком размере нужны общий язык, общая телеметрия и общая структура, чтобы многие люди могли согласованно действовать над системой, которой никто не владеет целиком.

Корпоративный и государственный контексты повышают каждую ставку. Регулируемые отрасли несут юридические обязательства по доступности, требования аудита и обязательную отчётность о сбоях. Сервисы для граждан должны демонстрируемо соответствовать опубликованным целям производительности и не могут просто погаснуть. Государственные бюджеты тратят деньги налогоплательщиков в условиях растущих мандатов устойчивости и нулевых выбросов. В этих условиях эксплуатация, надёжность и наблюдаемость (понимание внутреннего состояния системы по её внешним выходам) больше, чем операционная гигиена. Это инструменты подотчётности, безопасности и институционального доверия.

Главы этой части

  • 9.1 Инженерия надёжности сайтов: Применение программной инженерии к эксплуатации через определение надёжности с помощью SLI (показателей уровня обслуживания), SLO (целей уровня обслуживания) и SLA (соглашений об уровне обслуживания), использование бюджетов ошибок (допустимого отклонения от идеальной надёжности) для баланса скорости и стабильности, беспощадное сокращение рутины (повторяющейся автоматизируемой ручной эксплуатационной работы) автоматизацией и прогнозирование мощности, чтобы масштаб никогда не заставал врасплох.

  • 9.2 Наблюдаемость и телеметрия: Переход от мониторинга известных отказов к настоящей наблюдаемости, построенной на телеметрии, испускаемой системой (метрики, журналы, трассировки и события, связанные общими идентификаторами), стандартизация на нейтральном к поставщику OpenTelemetry (открытом стандарте генерации и сбора телеметрии) и проектирование оповещений, вызывающих людей только для действенных, видимых пользователю проблем.

  • 9.3 Управление инцидентами: Обнаружение, координация, разрешение сбоев и обучение на них через устойчивые ротации дежурств, ясную структуру командования инцидентом (определённую иерархию координации реагирования) с определёнными ролями и уровнями серьёзности, честную коммуникацию с заинтересованными сторонами и разборы без обвинений (рецензии инцидентов, нацеленные на системные причины, а не индивидуальную вину), доводящие корректирующие действия до завершения.

  • 9.4 Цена, устойчивость и зелёное программирование: Привнесение финансовой и экологической подотчётности в производство через видимость и оптимизацию FinOps (финансовых операций для облачных расходов), проектирование с учётом углерода (планирование работы на время и место, где электричество чище) и энергоэффективное, непрерывный подбор размера и намеренные компромиссы в триаде цены, производительности и надёжности.

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

  • 9.6 Хаос-инженерия и тестирование устойчивости: Построение уверенности, что система выдерживает турбулентные условия, через определение устойчивого состояния, формулирование гипотез и внесение реалистичных отказов с ограниченным радиусом поражения, от игровых дней к непрерывной автоматизированной проверке устойчивости.

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

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

Как эти главы связаны между собой

Эти четыре главы образуют тугой операционный цикл. Инженерия надёжности сайтов (глава 9.1) задаёт цели: SLI и SLO определяют, что значит надёжно, а бюджеты ошибок решают, когда замедляться. Наблюдаемость (глава 9.2) то, как вы измеряете и защищаете эти цели, поскольку оповещение по скорости сгорания SLO работает только с хорошо структурированной телеметрией, и это также то, как ответственные находят «почему» отказа. Управление инцидентами (глава 9.3) это то, что происходит, когда вы тратите бюджет ошибок быстрее запланированного: срабатывают оповещения из главы 9.2, включается структура командования, а получающиеся разборы без обвинений питают долговечные улучшения обратно в работу над надёжностью и инструментированием. Цена и устойчивость (глава 9.4) замыкают цикл. Они настаивают, что надёжность и производительность следует обеспечивать до SLO, определённых в главе 9.1, а не золотить везде, так что триада цены, производительности и надёжности балансируется намеренно, а не из страха.

Связи простираются далеко за пределы этой части. Владение надёжностью здесь формируется топологиями команд главы 1.2 и доставляется через конвейеры и платформенную инженерию глав 8.1 и 8.4, поскольку безопасное частое развёртывание предпосылка эксплуатации в масштабе. Культура без обвинений, ориентированная на обучение, делающая реагирование на инциденты честным, начинается в главе 1.1, а шаблоны надёжности и устойчивости под этими практиками основаны на архитектуре глав 3.3 и 3.5. Наконец, свидетельства, которые производят эти дисциплины, от готовой к аудиту телеметрии до разборов и отнесения цены, питают напрямую работу по рискам, гарантиям и управлению глав 10.2 и 11.3. При хорошей эксплуатации системы этой части то, что позволяет организации выполнять свои обещания долго после того, как код написан.