Привет!
Команда разработки Slack выложила отличный разбор своего инцидента, произошедшего 22 февраля.
Если кратко, то суть в следующем: обновление Consul привело к сбросу кэша, что стало причиной беспрецедентно высокой нагрузки на БД неоптимальными запросами. Настоящий эффект бабочки — обновление версии софта вызвало взрывной рост нагрузки.
Интересен раздел Learnings. С одной стороны, причины очевидны: узкое горлышко в БД, каскадный отказ, зависимость от горячего кэша и минорные изменения как триггер сбоя. С другой стороны, это стало ясно лишь в ретроспективе. В сложных системах, коими является любая более-менее крупная IT-инфраструктура, предсказать такие сбои практически невозможно.
Какие выводы я сделал из этого разбора:
✒️ 1. Невозможно предусмотреть и закрыть все возможные отказы в таком крупном проекте как Skyeng. Инцидент может случиться где угодно, когда угодно и почему угодно.
✒️ 2. Нужно больше уделять внимания инструментам, которые позволят быстрее узнавать об инцидентах и их митигировать: чувствительные мониторинги, детальные логи, подробные Disaster Recovery Plan и команда дежурных, готовых отработать инцидент 24/7.
Команда разработки Slack выложила отличный разбор своего инцидента, произошедшего 22 февраля.
Если кратко, то суть в следующем: обновление Consul привело к сбросу кэша, что стало причиной беспрецедентно высокой нагрузки на БД неоптимальными запросами. Настоящий эффект бабочки — обновление версии софта вызвало взрывной рост нагрузки.
Интересен раздел Learnings. С одной стороны, причины очевидны: узкое горлышко в БД, каскадный отказ, зависимость от горячего кэша и минорные изменения как триггер сбоя. С другой стороны, это стало ясно лишь в ретроспективе. В сложных системах, коими является любая более-менее крупная IT-инфраструктура, предсказать такие сбои практически невозможно.
Какие выводы я сделал из этого разбора:
✒️ 1. Невозможно предусмотреть и закрыть все возможные отказы в таком крупном проекте как Skyeng. Инцидент может случиться где угодно, когда угодно и почему угодно.
✒️ 2. Нужно больше уделять внимания инструментам, которые позволят быстрее узнавать об инцидентах и их митигировать: чувствительные мониторинги, детальные логи, подробные Disaster Recovery Plan и команда дежурных, готовых отработать инцидент 24/7.