17 января с 21:07 до 23:05 (мск) наблюдалась недоступность сервиса api.mindbox.ru для 100% клиентов.
Корневая причина проблемы — ошибка в конфигурации сетевого оборудования.
Во время инцидента клиенты не могли пользоваться административными панелями. Все синхронные входящие запросы в api завершались с ошибкой. Скапливалась очередь обработки асинхронных запросов. После восстановления доступности очередь обработалась в соответствии с квотами и периодом актуальности
Чтобы обеспечить высокую точность и согласованность при управлении сетевым оборудованием, мы используем NetBox как централизованную систему документирования сети и Ansible для автоматического развертывания изменений.
В ходе ночных работ по замене неисправного основного коммутатора (core switch) возникли изменения конфигурации, которые, не были своевременно отражены в NetBox. На следующий день при добавлении нового сервера эти изменения были отражены в NetBox, но без учета предыдущих ночных корректировок.
В процессе развертывания изменений мы используем Octopus Deploy, который представляет различия (diff) в конфигурациях перед их настройкой и требует внимательности от инженеров. В этот раз произошло упущение, и подготовленный к развертыванию дифф не был уточнен, что привело к ошибочному отключению сетевого интерфейса.
Расследование инцидента заняло большое количество времени, поскольку балансировщик нагрузки запросов для Octopus Deploy находился именно в той стойке, которая была отключена, в результате чего мы не могли оперативно проверить, было ли применено какое-либо обновление. После исключения проблем с DNS и Windows Server Active Directory, команда инженеров повторно проанализировала NetBox и обнаружила отключенный интерфейс. Восстановление сетевого соединения потребовало физического присутствия инженера в дата-центре, который после прибытия подключился к сетевому оборудованию и включил обратно сетевой интерфейс.
Для маршрутизации административных панелей и синхронизации сервисов мы используем Ingress Controller Traefik, развернутый на виртуальных машинах с размещением на разных физических серверах. Все физические серверы были установлены в одной стойке, что повлекло недоступность ключевых компонентов инфраструктуры при её недоступности. Таким образом при отказе стойки вся инфраструктура работала, но ключевой компонент, ингресс, оказался недоступен.
Обеспечим обязательное разделение рабочих нагрузок (anti-affinity) по разным стойкам:
Настроим автоматический откат изменений на сетевом оборудовании, если в процессе настройки была утеряна связность с настраиваемым устройством – 1е полугодие 2024.
Исправим баг с переполнением очереди асинхронных запросов, чтобы они не терялись во время недоступности – февраль 2024.
Добавим в конвейер поставки обновлений конфигурации предварительное тестирование полного слепка сети и связности внутри сети, на виртуальных машинах – 1е полугодие 2024.
Сделаем OOB Management - изолированную сеть для управления устройствами, чтобы обновление конфигурации устройств не могло привести к потере доступа к устройствам – 2е полугодие 2024.
После полного Anti-affinity всех рабочих нагрузок по стойкам будем двигаться к хаос-тестированию полного отключения стойки – в 2025 году.