GreenCore 
Тендеры и лиды
Информация
Практически каждая зрелая IT-компания рано или поздно сталкивается с необходимостью разбирать инциденты. Где-то падает высоконагруженный сервис, где-то срываются сроки релиза, где-то интеграция начинает работать нестабильно после очередного обновления. После подобных ситуаций руководители собирают команду, проводят встречу, обсуждают причины произошедшего и называют её postmortem. Формально процесс выполнен, однако через несколько месяцев аналогичная проблема повторяется.
На первый взгляд может показаться, что причина заключается в недостаточной квалификации инженеров или отсутствии необходимых процессов. На практике всё оказывается значительно сложнее. Основная проблема большинства postmortem вовсе не техническая, а организационная. Люди приходят на встречу не для того, чтобы понять, почему система дала сбой, а чтобы защитить собственную репутацию. Разговор постепенно превращается в поиск виноватого, команды начинают перекладывать ответственность друг на друга, а реальные причины инцидента остаются за пределами обсуждения.
Подобную картину сегодня можно наблюдать во многих российских компаниях. После масштабной цифровизации бизнеса количество сложных распределённых систем значительно увеличилось. Появились десятки интеграций, микросервисные архитектуры, гибридные облака, корпоративные шины данных, внешние API и огромное количество взаимосвязанных процессов. Вероятность возникновения инцидентов закономерно выросла, однако подход к их разбору во многих организациях остался прежним. Руководители по-прежнему пытаются найти человека, который допустил ошибку, хотя современные цифровые системы давно перестали зависеть от действий одного специалиста.
На наш взгляд, именно здесь начинается фундаментальное непонимание самой идеи postmortem. Его задача заключается не в оценке работы сотрудников. Его задача — сделать систему устойчивее после каждого сбоя. Если после разбора инцидента компания получила нового виноватого, но не получила новых механизмов предотвращения подобных ситуаций, значит, никакого postmortem на самом деле не произошло.
В мировой инженерной практике идея blameless postmortem существует уже не первое десятилетие. Google, Amazon, Atlassian, GitHub и многие другие технологические компании неоднократно рассказывали о том, что большинство серьёзных инцидентов становятся результатом сразу нескольких факторов. Неверное архитектурное решение может совпасть с недостатками мониторинга, отсутствием автоматических тестов, неактуальной документацией и высокой нагрузкой на инфраструктуру. Каждая из этих причин по отдельности могла бы не привести к аварии, однако их сочетание запускает цепную реакцию.
Российский рынок постепенно приходит к тем же выводам. Особенно хорошо это заметно в крупных корпоративных проектах, где над одной системой одновременно работают внутренние команды заказчика, подрядчики, специалисты по информационной безопасности, DevOps-инженеры, аналитики и представители бизнеса. Попытка объяснить любой серьёзный инцидент ошибкой одного разработчика выглядит слишком примитивной моделью для настолько сложной среды.
Интересно, что культура поиска виноватых оказывает негативное влияние далеко не только на атмосферу внутри коллектива. Она напрямую ухудшает качество последующих решений. Если сотрудники понимают, что любое признание собственной ошибки может стать основанием для дисциплинарных мер, они начинают скрывать информацию, осторожнее формулируют выводы и избегают обсуждения спорных архитектурных решений. В результате руководство получает не объективную картину произошедшего, а её максимально безопасную для участников версию.
Именно поэтому зрелые инженерные организации оценивают postmortem не по количеству найденных виновников, а по количеству системных изменений, которые появились после каждого инцидента. Чем больше компания исправляет процессы, автоматизацию, архитектуру и инструменты контроля, тем ниже вероятность повторения аналогичной ситуации.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13705 тендеров
проведено за восемь лет работы нашего сайта.
Во время реализации крупных проектов в IT-компании GreenCore команда регулярно сталкивалась с ситуациями, когда отклонения возникали не из-за ошибок конкретного разработчика, а из-за сложности самих процессов. Особенно хорошо это проявлялось в проектах с большим количеством интеграций, несколькими подрядчиками и десятками заинтересованных подразделений со стороны заказчика.
Именно в таких условиях становится особенно опасно искать простые объяснения сложным событиям. Если после каждого инцидента организация ограничивается поиском ответственного сотрудника, команда постепенно перестаёт обсуждать настоящие причины возникновения проблем. Внешне дисциплина может даже улучшиться, однако качество инженерных решений начинает снижаться.
Поэтому в компании GreenCore postmortem рассматривается прежде всего как инструмент анализа процессов. Во время разбора обсуждается не столько вопрос «кто допустил ошибку», сколько вопрос «почему существующая система позволила этой ошибке привести к последствиям». Подобная формулировка полностью меняет направление разговора.
Этот подход хорошо проявился при реализации проекта внедрения системы КОНКОРД. Итерационная модель разработки предполагала постоянное взаимодействие с заказчиком, большое количество интеграций и постепенное расширение функциональности. При такой организации работ отдельные отклонения были неизбежны, однако каждый подобный случай использовался для корректировки процессов управления требованиями, архитектурных решений и механизмов взаимодействия между командами. В результате проект постепенно становился устойчивее по мере собственного развития.
Похожая логика применялась и в проекте автоматизации согласования товарных позиций для «Газпром недра». Основная цель заключалась не только в ускорении процессов на 43%, но и в создании прозрачной цифровой среды, где большинство потенциальных ошибок устранялось ещё до того, как они начинали влиять на сроки согласования. Это стало возможным именно благодаря постоянному анализу причин возникновения отклонений, а не поиску сотрудников, которых можно было бы сделать ответственными за каждый отдельный случай.
По мнению CTO GreenCore, качественный postmortem заканчивается не определением виновника, а списком изменений, которые делают всю систему сильнее. Если после встречи изменились процессы мониторинга, были добавлены автоматические проверки, обновлена документация, пересмотрены архитектурные решения или появились новые правила взаимодействия команд, значит, разбор действительно принёс пользу бизнесу.
Одна из самых распространённых ошибок заключается в том, что отчёты по итогам postmortem становятся исключительно техническими документами. Они подробно описывают последовательность событий, журналы ошибок, особенности инфраструктуры и действия инженеров, однако практически ничего не говорят руководству компании о том, какие выводы были сделаны и как изменится работа организации в будущем.
Мы считаем, что генеральному директору значительно важнее получить ответы совсем на другие вопросы. Насколько снизилась вероятность повторения подобного инцидента? Какие процессы были изменены? Какие инвестиции потребуются для устранения выявленных рисков? Повлияет ли произошедшее на сроки реализации других проектов? Какое влияние инцидент оказал на финансовые показатели компании и каким образом будут минимизированы подобные риски в дальнейшем?
Когда postmortem начинает отвечать именно на эти вопросы, он перестаёт быть внутренней инженерной процедурой и становится полноценным инструментом управления компанией. Руководство получает возможность оценивать не сам факт возникновения проблемы, а скорость организационного обучения после неё.
Именно поэтому многие зарубежные исследования по управлению инженерными организациями рассматривают количество повторных инцидентов как гораздо более значимую метрику, чем количество первоначальных ошибок. Ошибки неизбежны в любой сложной системе. Гораздо важнее способность компании извлекать из них практическую пользу.
В ближайшие годы российские компании будут всё активнее инвестировать в развитие собственных цифровых платформ, импортонезависимых решений и корпоративных информационных систем. Вместе с этим неизбежно возрастёт сложность архитектур, увеличится число интеграций и возрастёт количество потенциальных точек отказа. Это означает, что полностью исключить инциденты не сможет ни одна организация, независимо от уровня квалификации её специалистов.
Настоящим конкурентным преимуществом станет не отсутствие ошибок, а способность компании быстро и системно превращать каждый инцидент в источник организационных знаний. Именно поэтому культура postmortem постепенно выходит далеко за пределы инженерных подразделений. Она становится частью общей модели управления бизнесом, где ценится не поиск виноватых, а постоянное совершенствование процессов.
Именно такой подход последовательно развивает GreenCore, при реализации сложных корпоративных проектов. Здесь postmortem рассматривается не как обязательная встреча после возникновения проблемы и не как инструмент внутреннего контроля. Его главная задача заключается в том, чтобы каждая ошибка повышала устойчивость архитектуры, улучшала взаимодействие между командами и снижала вероятность повторения аналогичных ситуаций в будущем.
Именно эта философия станет одним из признаков зрелых инженерных организаций в ближайшие годы. Компании, которые научатся извлекать знания из собственных ошибок быстрее конкурентов, будут выигрывать не только в качестве разработки, но и в скорости развития бизнеса в целом.
