Привет, Хабр. Меня зовут Кирилл Борисов, я SRE в Ситуационном центре. Я часто видел, как неправильное использование паттернов отказоустойчивости архитектуры или их игнорирование приводит к серьёзным последствиям. Поэтому хочу рассказать, как обеспечить надёжность в условиях, когда может упасть любой микросервис.

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

Когда алертов становится слишком много, это уже не инструмент мониторинга, а хаос. Мы начинаем их игнорировать, ставить чаты в мьют и надеяться, что, если что-то сломается, пользователи сами нам об этом расскажут.

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

Привет! Я — Кирилл Борисов. Сегодня я расскажу вам о том, как мы в VK боролись с лавиной алертов, какие решения нашли — и, главное, как этот опыт можно применить в любой команде.

Привет, Хабр! Меня зовут Кирилл, я работаю в IT более 13 лет. Сначала инженером по внедрению, потом DevOps, потом SRE, также работал руководителем группы сопровождения. Сейчас SRE в VK Рекламе, поэтому знаю, как важно делать правильные инструменты для анализа проблем. 

В любом проекте и компании я иногда сталкивался, а иногда сам создавал проблему: огромное количество дашбордов. Вспомните ситуацию, когда вы в Grafana ищете какой-нибудь дашборд, пишете, например, «Tarantool», и вам выпадает огромный список дашбордов, которые кто-то до вас насоздавал. Это могут быть кастомные дашборды, которые кто-то делал для какого-нибудь инцидента, или просто созданные другими специалистами. Часто бывает, что половина этих дашбордов нерабочие или на них нет чего-то полезного. 

Как правило, обилие дашбордов создаёт ряд проблем: информационную перегрузку, потерю фокуса, сложность восприятия, а самое главное, затруднение исследований инцидентов. Попробуйте себе честно ответить на вопрос: глядя на свой дашборд, вы можете понять, работает ваша система или нет? Если нет, то читайте дальше. 

Подход «инфраструктура как код» упрощает создание и управление инфраструктурой, но это всё ещё код, и относится к нему надо как к любому коду. А значит, нам нужно внедрять практики SDLC. О реализации одной из них и будет эта статья. А точнее, про тестирование инфраструктурного кода. 

Мы пользуемся Docker-провайдером, но это накладывает некоторые ограничения на запуск. Например, там нельзя редактировать файлы hostname, нельзя поставить нормальный файрвол и т. д. Эти ограничения иногда довольно болезненны, когда то же самое отправляешь в эксплуатационную среду, которая хоть и чуть-чуть, но отличается. Мы в проекте используем Ansible, и перед настройкой production-окружение хотим протестировать наши playbook. И для этого используем Molecule совместно с TestInfra. Как? Сейчас расскажем.