В конце января практика Хекслета не работала больше двух часов — это пока самый крупный сбой в этом году. Вместе с разработчиками Хекслета публикуем постмортем — детальный разбор проблемы с выводами, который поможет нам не допускать подобного в будущем, а студентам и практикующим разработчикам — не повторять наших ошибок.
Введение: постмортемы
Прежде, чем приступить к разбору инцидента, разберемся, для чего нужны и как устроены постмортемы.
В любой программе, кроме кода присутствуют элементы реального мира — разработчики, пользователи, вендоры, оборудование, пространство и время. С таким количеством участников невозможно гарантировать, что программа всегда будет работать без сбоев.
Раз сбои неизбежны, относиться к ним можно как к источнику потенциальной пользы. Для этого и нужны постмортемы — практика ведения документации о критических ошибках, последствиях и мерах по их предотвращению в будущем.
Часто в процессе написания постмортемов в системе обнаруживаются скрытые связи между компонентами, что делает практику вдвойне полезнее. Теперь разработчики знают не только слабые места, но и лучше понимают механизм работы программы.
Что случилось с практикой Хекслета
К сбою на Хекслете неочевидные связи не имеют никакого отношения — его причиной стал человеческий фактор. К нему привели отсутствие мониторинга и опыта быстрого восстановления сайта, который дает практика «чистых понедельников» (о ней подробнее расскажем ниже).
Глобально инфраструктура Хекслета состоит из двух частей. Сайт хостится на облачных серверах Google Cloud, а Cloudflare выступает прокси-сервером. Практика, где запускаются IDE с упражнениями и проходят тесты — хостится в облаке Digital Ocean. Она устроена так, что при запуске IDE отправляется запрос на свободный сервер с практикой, внутри поднимается docker-контейнер, а пользователь оказывается в редакторе кода со своей файловой системой, терминалом и прочим.
Читайте также: Как сохранять фокус на протяжении всего обучения: советы от Хекслета
В декабре 2021 года Хекслет для ускорения работы и других бонусов (встроенный CDN, сертификаты Cloudflare) переехал с облачных серверов Google Cloud на Cloudflare.
И сайт, и практика работали без проблем до 26 января. В этот день случился крупный сбой. Дальше события развивались так:
[16:13] Команда разработки получила первое сообщение о том, что сервера с практикой недоступны. Спустя 20 минут стало понятно, что у SSL-сертификатов, которые всегда обновлялись автоматически, истек срок действия. Предположив, что проблем носит локальный характер, разработчики пытались по одному ее решить.
[16:41] На общем созвоне разработчиков удалось установить проблему: система не могла автоматически получить новый сертификат, поскольку подтверждение владения сайтом через DNS перестало работать. Это произошло потому, что провайдером был прописан Google Cloud (который использовался до переезда), а не Cloudflare.
Ручное обновление сертификата на работающей машине не помогло. Тогда было принято решение либо запустить сервер практики через проксирование Cloudflare c ее сертификатами, либо перенастроить сервер на работу с другим типом верификации.
[17:25] Оба варианта не помогли: стало понятно, что быстро решить проблему не удастся. О сбое сообщили всем сотрудникам Хекслета и отделу маркетинга, студентов предупредили об отсутствии доступа к практике в соцсетях и внутреннем сообществе.
В это время разработчики перенастроили сервер практики на подтверждение через Cloudflare.
[18:00] Заработали первые сервера с практикой. Спустя 20 минут доступ к ней был полностью восстановлен.
Выводы
Причина, по которой возникла уязвимость, — отстутствие мониторинга доступности серверов. В декабре 2021 года Хекслет переехал с Google Cloud на Cloudflare, поэтому система автопродления сертификата пыталась работать со старым провайдером. В результате срок действия сертификата истек 26.01.2022 в 12:58 CET.
Падение можно было предотвратить: 15 и 24 января на почту support приходили письма-предупреждения от letsencrypt о сроке истечения сертификата. Команда разработки решила, что письмо штатное, а сервис автопродления сертификата сам продлит его в нужное время. До переезда эта система работала безотказно.
Как не допустить подобного в будущем:
- Настроить мониторинг доступности всех серверов (HTTP 200).
- Настроить мониторинг с алертами по проверке сертификатов на все домены в Slack.
- Начинать общий созвон разработчиков сразу после того, как стало понятно, что проблема массовая.
- Ввести практику «чистых понедельников». Она предполагает, что в определенный день разработчики «пересобирают» сайт с нуля.
- Перенастроить письма от letsencrypt на правильную почту.
Главная проблема в данном случае — человеческий фактор: если бы команда разработки не забыла перенастроить систему автообновления сертификатов, практика работала бы в штатном режиме. Надеемся, эта история поможет вам не повторять наших ошибок.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
