Что такое post mortem
Викторианская фотография post mortem, 18+
Все мы видели в кино живых актеров, загримированных под мертвых и изображающих трупы, нас это давно не пугает, мы ведь знаем, что живой человек, или кукла-макет, или нарисованный спецэффект. Мертвецов же, выдаваемых за живых, вы вряд ли видели. Возможно, кто-нибудь вспомнит фильм «Другие» с Николь Кидман.
Информация из Википедии:
Изобретение дагеротипа в 1839 году делает портретную съёмку доступной и популярной, в особенности для тех, кто ранее не мог позволить себе живописные портреты. Этот более дешёвый и быстрый метод создания портрета обеспечивал среднему классу возможность увековечивать память о своих умерших близких.
Такие фотографии служили не столько напоминанием о смертности, сколько своеобразным сентиментальным сувениром в память об усопшем. Особенную популярность получило фотографирование умерших детей и новорождённых, поскольку уровень детской смертности во времена Викторианской эпохи был весьма высок, и такие снимки иногда были единственными портретами детей, оставшимися семье на память.
Такие же штативы использовались и в магазинах одежды для поддержки тяжелых манекенов.
Мертвая девочка в окружении своих кукол
Очень известная фотография: снимок сестер Браун из Бостона, сделанный в 1890 году. Кэтрин – блондинка слева, – к моменту съемки была мертва. Вторая сестра, Сьюзан, умрет спустя несколько месяцев от той же болезни (вероятно, наследственной).
На этом фото мертв мальчик. Лично я сомневаюсь еще по поводу девочки в центре, но такой информации нет. Покойного выдают темные кисти рук.
Эту девушку в возрасте 18 лет переехал пополам поезд. Родственники «оживили» то, что от нее осталось, как могли.
По поводу этого фото у меня нет 100%-й уверенности. Ребенок мертв, но в некоторых источниках утверждают, что мама тоже.
Жив только мальчик с корабликом, оба близнеца мертвы.
Девочка мертва. Сзади виднеется штатив.
Мертвы все позирующие.
Мертва девушка, которая стоит (обратите внимание на темные кисти рук).
Одна из историй, связанных с фотографиями «пост мортем»:
В 1898 году в городе Клайндон, штат Арканзас, от воспаления легких умерла четырехлетняя Мэри Роулз. Для ее безутешных родителей это несчастье совпало с другим: в соседнем городе при смерти лежала бабушка покойной девочки, престарелая миссис Хегленд. Внучку она безмерно любила и всячески ее баловала; правда, в последнее время, будучи не в состоянии с ней видеться из-за своей болезни, она ограничивалась лишь посылкой ей подарков, главным образом кукол. Зная, что трагическое сообщение сократит и без того недолгие дни миссис Хегленд, родители малышки решились на обман. Мертвую девочку нарядили в красивое платьице, вокруг нее разместили присланных бабушкой кукол. Мэри, сидевшая со склоненной на бок головкой, как бы в задумчивости глядела на своих игрушечных подружек. Фотография была отправлена миссис Хегленд вместе с письмом, в котором сообщалось, что девочка в полном здравии и шлет любимой бабушке привет. Решив, что снимок утешит умирающую, убитые горем родители приступили к подготовке похорон дочки. Но история на этом не закончилась. Накануне погребения, поздно вечером, возле крыльца Роулзов остановилась карета, из которой, поддерживаемая служанкой, вышла миссис Хегленд. Роулзы знали, что она давно не встает с постели, и потому ее неожиданное появление оказалось для них ужасным сюрпризом. Миссис Хегленд, вопреки советам врачей, решилась на это путешествие с единственной целью: увидеть перед смертью дочь, зятя, а главное – любимую внучку. Войдя в дом, бабушка потребовала, чтобы к ней привели Мэри. «Я, может быть, не доживу до утра», – повторяла она слабым голосом.
Растерявшиеся родители ответили, что Мэри сегодня ночует у подруги. Старуху уложили в постель, но она, видимо, почувствовала что-то неладное. Среди ночи миссис Хегленд встала с постели, зажгла свечу и вышла из комнаты. В полутемном зале, освещенном луной, она увидела закрытый гроб. Подошла, с усилием сдвинула крышку. А когда отблеск свечи упал на мертвенно-бледное лицо юной покойницы, старуха вскрикнула и лишилась чувств. Пламя упавшей свечки перекинулось на креп и обивку гроба, на платье Мэри, и через считанные минуты огонь охватил комнату. А вскоре заполыхал весь дом.
Еще одна страшная история связана с этим фото:
Изображенная на фото девушка была единственной дочерью в семье. Когда она умерла, обезумевшая от горя мать наотрез отказывалась хоронить ее, спрятала тело в подвале и 9 дней держала во льду. Согласилась на похороны она только при условии, что дочь сфотографируют, что и было сделано: девушку нарядили, загримировали, дали в руки книгу, в результате получилось то, что вы видите.
В ЖЖ пользователь nmarika пишет:
«На данный момент эта тема является очень притягательной, наверное в первую очередь, потому что непонятна для нашего восприятия. Существуют множество коллекционеров, которые увлекаются такими фотографиями. Например, Коллекция Стенли Бёрнса одна из самых известных на сегодняшний день, около более 700 тысяч фотографий и дагерротипов.
Кстати, фотографии, которые показывают в фильме «Другие» самые что ни на есть настоящие, взятые из той же коллекции Бёрнса. Всё-таки не даром мне понравился этот фильм, было в этом эпизоде и правда что-то необычно жуткое.»
В этой статье я решила не выкладывать наиболее леденящие кровь неподготовленного человека фотографии (в особенности младенчиков с открытыми-нарисованными глазками, и подобных жутковатых взрослых. Если вы не сильно испугаетесь и слегка привыкните к мрачной эстетике викторианских «пост мортем», могу насобирать и выложить еще подборку.
Благодарю тех, кто смог дочитать статью до конца.
Портал №1 по управлению цифровыми
и информационными технологиями
“Цена неудачи – образование”
Девин Каррауэй (Devin Carraway).
“Вскрытие покажет” – знакомая многим фраза, это когда мертвые учат живых. Обычно вскрытие проводят, чтобы выяснить и проанализировать причину смерти, только оно уже никак не поможет умершему.
Каждый, кто работал с технологиями, проектами, услугами сталкивался со сбоями или неудачами. Разные масштабы, разные последствия — все имеет свою цену. А можно ли было избежать мелких проблем, значительных неудач или глобальных катастроф? У всего есть причина и следствие. Или если уж это произошло, то как мы должны на это реагировать и какие уроки вынести?
Есть два подхода, позволяющих учиться на прошлых ошибках и избегать их в будущем:
Post-mortem
В процессе создания, предоставления, совершенствования услуг, мы неизбежно сталкиваемся с инцидентами. Техника выходит из строя, люди делают ошибки, процессы не совершенны – все это проявляется в инцидентах. Назначение практики управления инцидентами – минимизировать негативное влияние за счет скорейшего восстановления нормальной работы услуги. Но быстро восстановить услугу – это не избавиться от инцидентов. И если не будет формализованной деятельности изучения первопричин инцидентов, то мы можем работать в режиме пожарной машины бесконечно, прилагая героические усилия в лечении симптоматики, а не болезни. Анализ возникновения инцидентов и устранение первопричины инцидентов – задача для практики управления проблемами. Но как мы исследуем возникающие инциденты? Применяем ли подход посмертного вскрытия и как мы это делаем?
Post-mortem – это задокументированный отчет об инциденте, его последствиях, предпринятых действиях для минимизации или устранения причин, а также предотвращения повторения инцидента. Все это напоминает обзор после восстановления значительного инцидента. Не так ли? Основная цель такого отчета или обзора – это изучение и документирование и понимание основных причин инцидента, принятие превентивных мер, уменьшающих последствия или вероятность возникновения инцидентов. Важно понимать, что при анализе первопричин мы не должны играть в игру поиска крайнего и виноватого в возникновении инцидента. Мы не должны уничижать себя, посыпая голову пеплом. Post-mortem обзор не является наказанием, это возможность для роста, возможность вынести урок из происшедшего для всех.
Понимаю, что, читая эти строки, найдутся и противники идеи не искать виноватого. Когда что-то идет не так, всегда хочется найти виновного. Поиск крайнего заставляет людей “защищаться”, скрывать истинные причины неудач, чтобы избежать наказания. Это явно не способствует открытости, доверию и гарантиям конструктивности, дающим право ошибаться, экспериментировать, улучшать и развивать инновации.
Post-mortem без обвинений (Blameless PostMortems) – это часть внутренней культуры в компании, требующей постоянных усилий. Но выгоды от такой культуры очевидны:
Post-mortem — это способ выстроить процессы вашей команды и активизировать сотрудничество, поощряя культуру открытого обсуждения острых вопросов, совершенствования, поиска решений, а не поиска крайнего.
Pre—mortem
Минута профилактики стоит часов восстановления – эта истина хорошо известна. Но не все задумываются о возможных последствиях. Можно ли их предотвратить? Можно! И здесь поможет Pre-mortem.
Pre-mortem является гипотетической противоположностью Post-mortem’a. В бизнес-обстановке Pre-mortem проводится перед началом проекта, а не в конце, это поможет улучшить проект, а не заставит сокрушаться из-за последствий неудач, когда ничего уже не исправить.
Pre-mortem – это управленческая стратегия, которая позволяет представить, что проект провалился. Такая техника дает возможность оценить ситуацию еще до достижения конечного результата, т. е. проанализировать потенциальные угрозы, лучше подготовиться или даже предупредить потенциальные риски. Кроме этого, если команда заранее представляет провал, она сможет сохранить равновесие при любых обстоятельствах.
Подход Pre-mortem может быть применен при управлении рисками, управлении проектами, проактивной работе практики управления проблемами, проектирования услуг, тестирования и др.
Что потребуется для Pre-mortem анализа:
Учтите, нет никаких гарантий, что все будет гладко и легко. Не всегда можно предугадать или предвидеть все возможные ситуации развития событий, но имеет смысл сыграть в игру под названием “Предсмертный анализ”. Она стоит вашего душевного спокойствия в будущем.
Преимущества такого подхода:
Pre-mortem или Post-mortem – игры стоят свеч. Они могут стать хорошим дополнением вашей корпоративной культуры.
Post mortem
После завершения (с любым итогом) проекта менеджер обязан написать т.н. «post mortem». Цель очевидна: сделать хорошее и плохое, что было в ходе проекта явным как для себя, так и для других. Если бы жанр таких post mortem стал более популярен у нас, уверен, процент успешных проектов от этого вырос бы, какими бы ни были критерии «успешности».
В этом тексте я опишу часть истории проекта в весьма бурно сейчас развивающемся домене TNC (Transportation Network Companies), а более точно – ROD (Ride on Demand). Если совсем по-простому, сервис заказа такси. В середине прошлого года одна достаточно крупная западная TNC (далее – «Энтерпрайз») приобрела в России игрока регионального уровня, б.ч. бизнеса которого была сосредоточена в средней полосе России. У этого игрока, назовём его «Такси 666», имелось семейство продуктов собственной разработки: приложения на Андроиде для клиентов и водителей, а также ряд Delphi-приложений, необходимых для управления таким бизнесом (принятие водителей, просмотр статистики и пр.). Отдельно стоит упомянуть Delphi-приложение для операторов, принимающих заявки по телефону. Особенностью, отличавшей модель бизнеса Такси 666 от наиболее известных TNC вроде Uber’а, было то, что телефонные заказы занимали долю около 80%, при этом никакой тенденции к увеличению доли заказов через приложение не наблюдалось. Тем не менее, Энтерпрайз воспринял такое положение вещей не как проблемную ситуацию (за которой много чего скрывалось – см. ниже), а как своего рода конкурентное преимущество для России с её необъятными просторами и в целом ещё низкой (но быстро растущей) долей проникновения мобильного Интернета.
Итак, аудит, в т.ч. технологический, был проведён, и сделка состоялась. Первые ошибки были допущены ещё в тот момент:
Ошибка №1. У агентов Энтерпрайза не было никакого запасного плана на случай, если основатель Такси 666 и его бессменный гендиректор (далее – «Генерал») решил бы покинуть компанию. Искать замену ему даже не начинали. Поняв это, Генерал использовал данный факт для постепенного установления почти полного контроля над агентами. Так «хвост стал вилять собакой».
Ошибка №2. IT-аудит был проведён поверхностно, и не выявил один из двух основных рисков для осуществления наполеоновских планов Энтерпрайза по экспансии вглубь России. Имя этому риску – «Firebird». Все Delphi-приложения были завязаны на использование данной СУБД, выбранной в качестве стандарта главой команды R&D (далее – «Главный Гад», «ГГ») Такси 666 около 15 лет назад. Основной проблемой, в дальнейшем постоянно тревожившей весь комплекс, стала нестабильность работы, обусловленная неспособностью Firebird справиться с резкими пиковыми нагрузками в ЧНН (Часы Наибольшей Нагрузки). Особенно же трудноустранимый характер данная проблема имела в свете наличия в БД хранимых процедур, в которых была сосредоточена б.ч. логики комплекса. Численность этих «хранимок» измерялась сотнями. Был и второй важный риск, не выявленный аудитом. О нём будет сказано ниже.
Как уже было сказано, в Такси 666 существовал собственный R&D отдел, бессменно возглавляемый ГГ. Отношения между ГГ с его отделом и остальной частью бизнеса были сложными. Настолько сложными, что некоторые рядовые члены отдела приторговывали «на сторону» продуктами компании, а сам ГГ незадолго до сделки с Энтерпрайзом сговорился с конкурентом. В результате, спустя без малого 2 месяца со дня закрытия сделки, весь R&D в полном составе снялся с места, сел на самолёт и улетел к конкуренту в далёкие тёплые края. Справедливости ради скажу, что такой форс-мажор трудно было предугадать, и это был риск, который ни в какие матрицы не укладывался. Тем не менее, его можно было минимизировать по крайней мере двумя способами:
Способ №1. Прописать требованием к сделке создание подробной документации комплекса. Оной документации в Такси 666 не существовало от слова «вообще», и как потенциальный риск данный факт также воспринят не был.
Способ №2. Прописать для продавца приобретаемой компании обязанность обеспечить сохранение R&D отдела в течение некоторого переходного периода. С драконовскими санкциями в случае невыполнения. Спецы по M&A, если вы меня читаете – возьмите это на заметку.
Прежде чем продолжить, мне следует сказать пару слов о «наполеоновских планах» Энтерпрайза на момент приобретения Такси 666. Они предполагали увеличение кол-ва городов присутствия с десятков до сотен в срок, измеряемый 1,5-2 годами. Иметь амбициозные планы – это хорошо. Не иметь процесса пересмотра таких планов в случае резкого изменения обстоятельств – очень плохо. Вот так и была сделана ещё одна ошибка:
Ошибка №3. Внезапная полная потеря отдела разработки не была расценена как резкое изменение обстоятельств. Наполеоновские планы остались прежними.
Тем не менее, не признать, что в компании разразился кризис, было невозможно: комплекс элементарно требовал людей для техподдержки. Поскольку медлить было нельзя, агентами, срочно прибывшими из Москвы, были наняты несколько толковых специалистов за умопомрачительные зарплаты. Они смогли стабилизировать работу комплекса. Это, кстати, стало одним из немногих правильных шагов на протяжении всего проекта.
Правильный шаг №1. Под угрозой worst case scenario надо действовать стремительно и не считаться с расходами.
В то же время, после прохождения пика кризисной ситуации не было предпринято необходимых мер по сворачиванию «антикризисного штаба»: замены крайне дорогих спецов на более дешёвых и нахождения постоянного руководителя в отдел. Так была допущена следующая ошибка:
Ошибка №4. Антикризисный IT-менеджер Энтерпрайза был назначен IT-директором Такси 666. Это было плохим решением по целому ряду причин. Во-первых, человеку, имеющему троих маленьких детей, приходилось бывать в командировках по графику «4 дня через 3» на протяжении нескольких месяцев. Во-вторых, этот человек совершенно не знал местной специфики рынка труда в IT-сфере, что привело как к досадным ошибкам (вроде найма Junior Developer’а на позицию Senior’а за з.п. в 100 т.р.), так и в целом очень медленному процессу найма персонала. В-третьих, его назначение прошло «мимо» Генерала, в результате чего работа обоих вскоре дополнительно осложнилась тлеющим конфликтом.
Дальнейшее развитие событий проще всего описать как ряд следствий из ранее сделанных предпосылок:
Для кого я написал этот текст? В первую очередь, для высшего руководящего звена. Коль скоро в вашем распоряжении большие финансовые ресурсы, убедитесь, что управляют ими компетентные менеджеры, которые умеют находить скрытые риски и понимают, что на каждый из них должен быть заранее разработан план действий. Во вторую – для амбициозных молодых людей вроде меня, которые думают, что своими идеями могут изменить мир к лучшему. Прежде чем пускаться в новое предприятие, здраво оцените не только цели и ресурсы ваших партнёров, но также адекватность и профессионализм их менеджеров. Работать надо в команде единомышленников.
Зачем и как мы пишем постмортемы по критичным багам
В какой-то момент у нас стало много хотфиксов — стабильно больше половины деплоев на проде были хотфиксы или откаты. Мы решили анализировать каждый хотфикс, чтобы понять причины, найти системные закономерности и устранить их, не допуская два раза одних и тех же ошибок. Как говорил Джейсон Стейтем (Стэтхэм? Стэтэм?): «Не страшно ошибаться, страшно повторять одну ошибку 2 раза». Ну и мы решили не повторяться. В статье расскажу как мы анализируем хотфиксы и другие критичные проблемы, что у нас получается, а что нет, с какими сложностями столкнулись и как их решали.
Как было раньше
Раньше на проде случались хотфиксы-откаты из-за критичных багов. Мы в QA понимали что нам нужно проводить какую-то ретроспективу по пропущенным багам на прод. Поэтому после каких-то очень проблемных релизов:
собирались и обсуждали проблему;
звали разработчиков, участвующих в этом релизе;
принимали решения (некоторые работают до сих пор).
Основная проблема при таком подходе, что ты не разбираешь каждый хотфикс или откат детально. Ты обращаешь внимание только на очень критичные проблемы. Такая активность не системная.
Когда хотфиксов стало много (примерно половина всех выкладок на прод были хотфиксы) поняли, что этого недостаточно — нужно что-то менять. Мы решили попробовать практику написания постмортемов на хотфиксы и откаты.
Что такое постмортем?
Вообще, постмортем — это посмертная фотография родственников.
Мы узнали об этой практике у нашей команды Платформы. Они уже с 2018 года ведут постмортемы по всем инцидентам в системе.
Постмортем для примера.
Наши люди даже выступали с этими темами на конференциях.
В этом подходе детально разбирается каждый инцидент, вырабатываются экшен айтемы (action items) для устранения и недопущения проблем. Мне этот инструмент показался черезвычайно полезным и мы решили попробовать адаптировать его под наши нужды.
Как начали вести
Мы почитали о практике ведения постмортемов, чтобы не допустить критичных ошибок при их написании. Пошли в репозиторий с постмортемами от команды Платформы, почитали их постмортемы и на основании их шаблона сделали свой (шаблон будет в конце статьи).
Вначале мы вели постмортемы в Nuclino. Но в нём сложно трекать статус каждого постмортема, выполняемость решений и т.д. и т.п. А вот в Kaiten наглядно видно текущий статус постмортема, какие из них без решений, можно строить какие-то отчеты. Поэтому наши постмортемы логично переехали туда.
Скрин с Kaiten.
Чуть поработали и поняли, что у нас есть несколько типов критичных проблем и под каждый из типов создали свой шаблон: некоторые вопросы были актуальны для одного типа, но неактуальны для другого. В итоге получилось 4 типа постмортемов:
По хотфиксам на проде.
По откатам релизов.
По «подливкам» в релиз — когда в релизную ветку подливают фиксы. Иногда на этапе прогона тестов находятся критичные баги. Если бы они попали на прод был бы хотфикс, иначе их бы пофиксили стандартным флоу в следующем релизе.
По STL (Stop the Line). Подробнее что это такое можно почитать в статье «Stop the line или прокачай свой pipeline, йоу»
Пример шаблона для хотфиксов из Kaiten.
Структура и способ ведения
В этом разделе расскажу о структуре шаблона на примере постмортема для хотфиксов. Возьмем один из недавних постмортемов, когда мы делали хотфикс.
Пишем дату хотфикса. Не всегда карточки создаются в тот же день, что и постмортем, поэтому решили проставлять дату случившегося события. Трекинг длительности исправления задач делает Kaiten и выдает нам в отчете. Кроме этого по дате инцидента можно сделать более глубокий анализ, посмотреть частотность по темам, выявить закономерности.
Авторы постмортема. Знаем к кому идти за подробностями инцидента или с уточняющими вопросами по решению. Наличие авторов постмортема не противоречит принципу написания постмортемов «blameless culture». Мы не обвиняем никого в доведении до проблемы, а хотим лишь отобразить участников разбора.
Причины. В этом блоке описываем причину которая привела к хотфиксу, что с технической точки зрения произошло. Стараемся выяснить корневые причины случившегося.
Проблемы. Пишем о том, с какими проблемами могли столкнуться наши пользователи. Какую функциональность мы задели, какие непотребства видели наши пользователи. Или что видели мы, если мы заметили проблему раньше пользователей (алерты, подскочившие графики в Grafana).
Потери. В этом блоке пишем влияние на бизнес, сколько задето пиццерий или пользователей, сколько потеряли в деньгах или во времени (это импакт на пользователей).
Что делать, чтобы ситуация не повторилась. В этом блоке пишем, что можно сделать чтобы не допустить эту проблему в будущем — решения, которые позволят на ранних стадиях заметить проблему или вообще устранить.
Разное. Это поле добавили как свободный ответ в анкетах, вдруг какая-то важная мысль не уложится в заданный нами шаблон. Иногда его заполняют, иногда нет.
Шаблон
Здесь оставлю пример шаблона наших постмортемов без моих комментариев.
## Последствия для бизнеса
## Предложения по недопущению в будущем
## Как можно было избежать проблемы (представь что у тебя есть машина времени и ты вернулся к моменту, когда ты еще не написал этот код, что можно было сделать, чтобы не было хотфикса)
**Создать картохи на написание _автотеста_ по этой проблеме в своем бэклоге и прикрепи их сюда как дочерние**
**Создать картохи по _недопущению хотфикса_ в будущем в своем бэклоге или бэклоге владельцев компонента и прикрепи их сюда как дочерние**
## Что ещё хочется добавить
**Не забудь поставить теги компонента в котором случилась проблема**
Берите себе, адаптируйте и пользуйтесь.
Сложности и как их решали
С «нахрапа» не получилось ввести постмортемы и вести их идеально. Вот наш список проблем.
Не заполняли постмортемы. Банально — да: поначалу люди ответственные за релиз забывали заполнять постмортемы…
Решили проблему добавив в чек-лист «релизмена» пункт о необходимости заполнения постмортема. «Релизмен» — разработчик отвечающий за выкатку релиза, ротируется после каждого релиза.
И проблема решилась. Остались единичные случаи, когда постмортем не заполняется. В таком случае в ручном режиме «тыкаем» ответственного и просим его заполнить. Владелец и хранитель процесса — QA-гильдия.
Не предлагали решений или предлагали слабые решения. Сейчас основная проблема в том, что почти в половине постмортемов нет решений или они очень общие типа «распилить монолит», «тестировать перед мержом в дев», «писать код без багов, а с багами не писать».
Проблему решили припиской в чек-листе, что когда QA пишет постмортем, он должен позвать другого QA. Мы прямо в процессе написания постмортема можем дать обратную связь о слабом решении или вообще о его отсутствии. Либо после написания постмортема нам отправляют его на ревью и мы так же даем обратную связь только уже асинхронно.
Скрин с чек-листа.
Не создавали карточки на решение проблем. Мы используем Kaiten и настроили доски так:
прикреплённая дочерняя карточка с устранением проблемы берется в работу;
постмортем автоматически переезжает в «In progress»;
когда задачу завершают — завершается и постмортем.
Это помогает не мониторить исполнение постмортемов.
Поначалу карточки не создавались, а даже если создавались, то не прикреплялись как дочерние и постмортемы не двигались. Решили тоже просто добавив в шаблон пометку о том, что нужно создать карточку и прикрепить её как дочернюю.
Решения долго берут в работу. Мы все понимаем, что бэклогом владеет продакт и у него есть приоритеты. Мы понимаем, что когда команда берёт техзадачи в спринт, это зависит от множества факторов: понимания продактом важности этих технических задач и последствий (если их не решить), от зрелости самой команды, критичности сервиса и проблемы. Но проблема всё равно болезненная.
Мы провели небольшую аналитику по среднему времени ожидания постмортема до момента когда над ним начали работу. Получилось, что медианное время ожидания постмортема до взятия в работу меньше месяца — 21 календарный день. По результатам навесили на колонку напоминание: когда карточка висит в ToDo дольше, она начинает привлекать к себе внимание.
Когда появляется сигнал мы идем к команде, которая должна решить эту проблему и спрашиваем о судьбе этой карточки. Иногда они становятся неактуальными, это тоже нормально.
Случаются повторные ошибки. У нас была ситуация, когда невыполненное решение одного из постмортемов привело к другому постмортему. Одним из решений когда-то было написать и прогонять нагрузочные тесты на роль Менеджер смены. Команда нагрузочного тестирования не успела взять её в работу и мы словили критичный баг на проде, который можно было бы обнаружить на нагрузочных тестах.
Результаты в цифрах
Мы проанализировали постмортемы за пол года, и вот какая картина получается.
Треть наших постмортемов не имеют конкретных решений на доработку и недопущение проблем в будущем.
Половина наших постмортемов в которых есть конкретные решения ещё не выполнена.
49 дней — медианное время жизни постмортема от появления на доске до выполнения (из тех что выполнили и в которых были решения), а среднее — 82 дня. Такие различия обусловлены большим разбросом значений. Критичные решения или очень простые решаются достаточно быстро, сложные и не критичные могут долго провисеть в ожидании.
Ситуация не радужная, но благодаря ведению этих постмортемов мы знаем о проблеме и можем предпринимать действия по её улучшению.
Выводы
Наше следующее направление по работе с постмортемами после обсуждения на гильдии — сфокусироваться на том, чтобы повысить процент постмортемов, в которых было какое-либо решение.
Мы решили сконцентрироваться на постмортемах без экшен айтемов. Моя первая мысль была: «Не лучше ли фокусироваться на выполнении постмортемов?». Однако, после некоторого обсуждения на комьюнити, мы пришли к выводу, что если пишется постмортем — то должен быть экшен айтем, иначе это «бесполезная работа». Поэтому мы решили увеличить этот процент, а после его увеличения взяться за повышение исполняемости этих постмортемов.
Ведение постмортемов по критичным функциональным багам на проде мне кажется полезной практикой. Мы явно проговариваем и анализируем каждую проблему, которую не хотим больше повторять. Мы получаем конкретные решения каждой проблемы. И в целом наша система становится лучше и меньше подвержена ошибкам.
Что ещё почитать.
Подписывайтесь на чат Dodo Engineering, если хотите обсудить эту и другие наши статьи и подходы, а также на канал Dodo Engineering, где мы постим всё, что с нами интересного происходит. А ещё есть группа в ВК (ну мало ли).