Привет, я Владислав Алмазов, директор по сопровождению информационных технологий (IT Operations) в Lamoda. Одно из направлений, за которое я отвечаю — uptime. Это количественный показатель непрерывной работы нашей платформы.

Дать возможность клиенту найти товар в каталоге, положить его в корзину, выбрать способ доставки, рассчитать скидки и оплатить — все это значит «оформить заказ». Одноименная кнопка доступна на сайте 99,95% времени в году. Оставшиеся 0,05% — это 4 часа в год, которые клиенты не замечают. Эта метрика отражает основное бизнес-требование к непрерывности самых критичных IT-систем. Час простоя для Lamoda — это потери десятков миллионов рублей.

По итогам прошлого года мы превысили план и наш uptime составил 99,96%. Дальше я расскажу, за счет чего это удалось.

Основная задача IT Operations — непрерывность бизнеса. В составе моего отдела работают пять технических направлений. Два из них — глобальные саппорты для всей компании, которые отвечают за техническую поддержку сотрудников, офисов, складов, сети доставки и контакт-центров.

Еще три направления занимаются инфраструктурой:

• информационная безопасность (ИБ) отвечает за техническое обеспечение информационной безопасности, ее аудит и контроль;
• телекоммуникации и датацентр обеспечивают бесперебойную работу всего железа и телекоммуникаций, в том числе телефонии и корпоративной сети в датацентрах, офисах и контакт-центрах;
• DevOps отвечает за инфраструктуру прода и QA, непрерывную доставку кода на прод и бесперебойную работу этого самого прода.

Рецепт uptime

Как и у всех, у нас случаются инциденты. Чтобы уменьшить их последствия, мы создали команду управления инцидентами, в которую входят представители разных отделов. Они круглосуточно мониторят состояние датацентра, сетевых каналов связи и компонентов серверных платформ, работу приложений и бизнес-логики, а также собирают все логи с наших систем, смотрят на графики и реагируют, если что-то пошло не так. Система мониторинга позволяет оперативно и даже проактивно реагировать на инциденты. За минуту она способна оповестить всех дежурных, которые назначаются по всем компонентам системы.

Основной показатель — это время реакции. Например, время реакции на критический инцидент — не более 5 минут, но чаще все происходит мгновенно, благодаря автоматизированной системе оповещений. В случае инцидента она дозвонится до дежурного, и при необходимости проведет эскалацию. Мы доплачиваем за такую работу, поэтому дежурные всегда на связи. Например, они никогда не отправляются в пятницу в бар без ноутбука :) Система работает хорошо, и пока у нас нет необходимости в создании круглосуточной системы дежурств в офисе, например, полноценного SRE — это экономически необоснованно.

Обычно дежурят команда Devops, сетевики, безопасники, а также разработчики, так как часто для решения инцидента необходим hotfix. Мы умеем делать hotfix за считаные минуты и выкатывать его на прод, соблюдая все необходимые процедуры и сохраняя возможность сделать rollback. Это помогает нам сохранять высокие показатели uptime.

У нас много расписаний дежурств. Первая линия поддержки работает круглосуточно и первая же реагирует на любые инциденты. Вторая линия сопровождает бизнес-системы, доставку и офис.

У Devops две команды дежурных: одна отвечает за uptime всех платформ онлайн-магазина, которые работают на Linux, а вторая занимается Windows-платформами, например, Active Directory. Дежурные ИБ (SecOps), отвечают за сегментацию сети и инциденты информационной безопасности, а также за управление доступами (IAM). Дежурные сетевые инженеры — за сеть в ЦОД и распределенные сети. Дежурные разработчики отвечают за наборы микросервисов, в которых они обладают техническим лидерством.

Мы соблюдаем стандарты информационной безопасности — NIST-800 и PCI DSS. Основные компоненты платформы изолированы друг от друга: нет открытой связности между 170 микросервисами онлайн-магазина, а также между другими системами, например ERP и платформой данных и аналитики. Следование таким стандартам позволяет нам снижать риски влияния угроз ИБ на наш uptime.

Команда информационной безопасности отвечает в том числе за сегментацию сети. Наш периметр защищен от DDoS и направленных атак. Ежегодно мы проводим тесты на проникновение, а также работаем с программой Bug Bounty, которая в этом году официально станет публичной — на данный момент исследователи («белые хакеры», которые взламывают системы по заказу самой компании) работают по приглашению.

Если говорить о технических мерах, которые помогают нам пассивно бороться с инцидентами, то это, конечно, физическое резервирование. Датацентр отвечает за все, связанное с электропитанием, охлаждением и физической безопасностью. Все системы продублированы и это подтверждено сертификатом TIER III. Как-то раз в разных частях нашего датацентра на расстоянии 30 метров в течение часа были повреждены два ввода питания, и мы фактически полтора дня работали на дизельном электрогенераторе. На работу это никак не повлияло, и все оборудование функционировало в штатном режиме.

Сети, каналы связи и оптоволокно — у всего есть дубли. Можно взять любой кабель в датацентре, выдернуть его и ничего не произойдет — все продолжит работать в штатном режиме. Мы регулярно проводим учения и тестируем систему.

Вообще, мы очень любим темное волокно — это относительно недорого и надежно. Например, у нас два канала волокна по 10 gbps до центрального офиса, фотостудии, сервиса защиты от DDoS, распределительного центра и других объектов. Также у нас есть своя автономная система (AS) и два блока провайдеронезависимых адресов, что позволяет подключаться к интернету у разных провайдеров и иметь пиринг на площадке MSK-IX со скоростью 10 gbps. Тут у нас стопроцентный uptime.

Что нужно, чтобы все работало

Достигать высоких показателей нам помогает резервирование сетевого оборудования: кластер ядра сети, кластеры фаерволов, по два top-of-rack коммутатора, четыре пограничных маршрутизатора. Также у нас есть протоколы отказоустойчивости, например, LACP и протоколы динамической маршрутизации EIGRP и BGP.

Выбор железа — еще один важный фактор, влияющий на uptime. Мы ориентируемся на качественных вендоров, оценивая их надежность и способность к непрерывной работе. Наша сеть построена на базе Cisco, что позволяет достигать максимальных уровней uptime железа годами.

Система резервирования вычислительных ресурсов построена на гипервизорах, поэтому выход из строя одного сервера приводит к переводу всех виртуальных машин на другой. То же самое относится и к хранилищу данных, где мы используем CEPH.

На следующем уровне работы наших приложений, которые относятся к онлайн-магазину, все крутится в Docker и управляется Kubernetes, у которого высокий уровень отказоустойчивости. Тут могут быть лишь секундные потери, если ноды выйдут из строя. В качестве сетевого решения, а также для обеспечения сегментации микросервисов, мы используем Calico. У всех подов есть маршрутизируемые адреса, которые анонсируются по протоколу BGP (Border Gateway Protocol) в корпоративную сеть. Все микросервисы для обмена между собой работают по правилу deny-any-any, поэтому у нас тысячи строк yaml-конфигураций фаервольных правил, а каждый новый микросервис проходит строгую проверку ИБ.

Часто именно базы данных (DB) становятся точкой отказа и могут повлиять на uptime. Наша платформа построена так, что в определенный момент времени есть только одна Master DB, с которой работает конкретное приложение. Но также есть еще от одной до шести Slave DB, у которых есть полная копия Master, но они работают только на чтение. В результате помимо распределения нагрузки, у нас присутствует избыточность данных, в том числе в целях реализации плана непрерывности бизнеса (BCP/DRP).

Для автоматического переключения в случае отказа Master DB мы используем решение Patroni, которое все делает автоматически. Это позволяет снизить downtime до минимальных значений. Был случай, когда до внедрения системы резервирования, сервер, на котором крутилась одна из критических баз данных, вышел из строя. Это случилось в полночь и нам потребовалось всего 9 минут на решение этой проблемы. Три минуты ушли на реакцию инцидент-менеджера, системы мониторинга и подъем дежурного инженера DevOps. Шесть минут ушло на подключение к сети, оперативный анализ ситуации на основе уже имеющихся данных мониторинга и переключение на Master DB.

Не наступать второй раз на одни и те же грабли помогает глубокий post mortem анализ. Мы детально разбираем каждый случай: определяем масштаб проблемы, хронологию событий и системы, которые были вовлечены, затем проводим анализ действий и вводим превентивные меры.

Мы внимательно следим за нагрузкой нашей платформы, регулярно проводим нагрузочные и деградационные тестирования. В обычное время мы готовы выдержать трехкратную нагрузку от максимальной дневной, а в период акций, например, во время Black Friday, мы масштабируем платформу до возможности держать шестикратную нагрузку.

4 часа тишины

И тут вы спросите меня, где же прячутся эти четыре часа в год вашего downtime? Примерно половина, то есть два часа — это устранение проблем с багами в инфраструктурном софте и отказы железа. Тут, как правило, все решает перезагрузка и последующий анализ инцидента.

Еще четверть инцидентов или один час — последствия bad release, когда некачественно протестированный код попадает в прод. У нас выстроен серьезный процесс разработки, который проходит code review, unit- и интеграционные тестирования в автоматическом и ручном режиме. Перед релизом мы отправляем все на препрод: софт полностью обкатывается на продуктовых данных и только потом попадает в прод. Релизов может быть несколько штук в день, и в таком потоке случаются неожиданные неприятности.

И еще один час downtime — это человеческий фактор. Был случай, когда наш новый инженер по информационной безопасности, выполняя достаточно рутинную операцию, внес в конфигурацию файервола ядра некорректное правило фильтрации. Это привело к остановке всего трафика в датацентре. Благодаря системе оперативного мониторинга изменений, мы выяснили причину и пофиксили это за 25 минут, а инженер даже не понял, что по его вине произошел инцидент, так как он случился с задержкой во времени. После этого появилось правило — 4eyes-review. То есть все подобные изменения катятся не в одни руки, а только двумя инженерами совместно, как и во многих других процессах.

Чтобы избежать downtime, все инфраструктурные изменения проводятся через так называемый RFC (Request for change). Этот набор правил касается выкатки на прод: чтобы внести изменения в инфраструктуре, инициатор описывает план действий, получает подтверждение другого инженера, и обозначает downtime в минутах. Для таких изменений мы выделяем определенное временное окно. Если нужно обновить софт на ядре и это приведет к downtime в 10 минут, то я согласую время с 4 до 6 утра. В это время происходит минимальное количество заказов, соответственно, импакт для бизнеса будет меньше.

RFC проводится несколько раз в неделю, чтобы минимизировать downtime. Тут у нас строгая дисциплинa: если все же downtime возможен, то он по факту он не должен оказаться выше, чем планировалось. Это учит грамотно оценивать уровень риска и не занижать его, даже если его вероятность — 0,01%. От того, насколько мы уложились в прогноз, зависит и наш KPI.

Напоследок скажу, что работа над uptime — это непрерывный процесс, требующий внимания, с учетом того, что любая онлайн-платформа растет и развивается очень быстро. В основном, управление инфраструктурой и рисками, кроме влияния на time-to-market, не зарабатывает деньги для бизнеса, но позволяет контролировать его расходы, снижая издержки и предотвращая резкие влияния серьезных инцидентов на финансовые показатели компании.