[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-postmortem::ru":3,"gloss-cluster-postmortem::ru":23,"gloss-next-postmortem::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"postmortem","cloud","Разбор инцидента","Разбор инцидента — это письменный документ, который делают после сбоя: что произошло, в каком порядке, что было затронуто, почему система это допустила и что в результате изменится. Он намеренно отделён от самого инцидента, потому что во время простоя цель — вернуть сервис, а после — понять его, и эти две цели требуют разного состояния ума. Дисциплина, ради которой разбор стоит потраченных часов, — это отказ останавливаться на человеке. Почти любой инцидент описывается фразой кто-то выполнил не ту команду, и описание это одновременно верное и бесполезное, потому что не объясняет, почему выполнить её было возможно, почему ничто её не поймало, почему эффект оказался таким широким и почему восстановление заняло столько времени. Разбор, называющий человека, производит одного притихшего инженера и ноль изменений в системе. Разбор, называющий условия, производит список того, что надо починить. Документ, которым пользуются, отличают от документа, который подшивают, три привычки. Пишите хронологию по свидетельствам, а не по памяти, включая пробелы: те двенадцать минут, когда никто не смотрел, обычно самая содержательная часть. Отделяйте то, что вы сделали бы снова, от того, что измените, потому что разбор, рекомендующий только больше внимательности, — это разбор без действий. И дайте каждому действию владельца и дату, а на следующем разборе проверьте список: самая частая неудача практики не в плохих разборах, а в хороших, чьи действия никто не выполнил. Наконец, держите их читаемыми и там, куда люди заглядывают: вторая и большая их ценность — быть записью для того, кто унаследует систему, когда все присутствовавшие уже уйдут. Короткое замечание об охвате. Полный документ нужен не каждому инциденту, и настаивать на обратном — верный способ похоронить практику под бумагами. Договоритесь заранее, какие инциденты его получают: обычно те, что дошли до клиентов, длились дольше некоторого срока или удивили тех, кто их разбирал, — а остальным хватит абзаца в канале.","Разбор инцидента объясняет, почему система его допустила, а не кто набрал команду. Привычки, отличающие рабочий документ от подшитого.",null,[11,14,17,20],{"slug":12,"name":13},"code-review","Код-ревью (Code Review)",{"slug":15,"name":16},"incident-management","Управление инцидентами",{"slug":18,"name":19},"runbook","Ранбук",{"slug":21,"name":22},"silent-failure","Тихий отказ (Silent Failure)",[24,28,32,35,38,41,45,48,51,54,57,60],{"slug":25,"category":5,"name":26,"updated_at":27},"air-gapped-deployment","Развёртывание без выхода в сеть","2026-09-09T03:30:02+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"autoscaling","Автомасштабирование (Autoscaling)","2026-09-08T21:32:36+00:00",{"slug":33,"category":5,"name":34,"updated_at":31},"availability-zone","Зона доступности (Availability Zone)",{"slug":36,"category":5,"name":37,"updated_at":31},"block-storage","Блочное хранилище (Block Storage)",{"slug":39,"category":5,"name":40,"updated_at":27},"bring-your-own-cloud","Развёртывание в своём облаке (BYOC)",{"slug":42,"category":5,"name":43,"updated_at":44},"budget-alert","Оповещение о бюджете","2026-09-08T21:32:37+00:00",{"slug":46,"category":5,"name":47,"updated_at":27},"change-freeze","Заморозка изменений",{"slug":49,"category":5,"name":50,"updated_at":27},"control-plane","Управляющий слой и слой данных",{"slug":52,"category":5,"name":53,"updated_at":44},"cost-allocation-tag","Метка распределения затрат",{"slug":55,"category":5,"name":56,"updated_at":44},"cost-chargeback","Внутреннее перевыставление затрат",{"slug":58,"category":5,"name":59,"updated_at":44},"cost-observability","Наблюдаемость затрат",{"slug":61,"category":5,"name":62,"updated_at":31},"disaster-recovery","Аварийное восстановление"]