Аудит инфраструктуры нужен не для отчёта, а для ответа на один вопрос: где система подведёт раньше всего и что с этим делать в первую очередь. Ниже чеклист, по которому можно пройтись самостоятельно за пару часов. Он не заменяет полную проверку с доступом к серверам, но даёт честную картину и список тем для разговора с командой.
Отвечайте на вопросы письменно и коротко. «Не знаю» — тоже ответ, и часто самый полезный.
Архитектура и точки отказа
- Есть ли актуальная схема: какие сервисы существуют, где развёрнуты, как связаны между собой и с внешними системами?
- Какой компонент, выйдя из строя, остановит всё? База данных, единственный сервер приложения, прокси, брокер очередей, внешний API?
- Что произойдёт, если упадёт один сервер? Сервис продолжит работать, деградирует или остановится?
- Есть ли зависимость от одного человека: сервер, который знает только он, скрипт, который написал он, доступ, который есть только у него?
Как читать. Если на второй вопрос несколько ответов, это нормально для небольшого проекта. Проблема — когда их никто не называл вслух и для них нет плана действий. Если на четвёртый вопрос ответ «да», это самый дорогой риск в списке, потому что его нельзя закрыть деньгами в момент аварии.
Мониторинг и алерты
- Как вы узнаёте о сбое: от системы мониторинга или от клиентов?
- Какие метрики собираются: только доступность или ещё время ответа, ошибки, очереди, место на дисках, срок сертификатов?
- Куда приходят алерты и кто на них реагирует в нерабочее время?
- Сколько алертов в неделю оказываются ложными или игнорируются? Если команда привыкла их пропускать, настоящий алерт пропустят тоже.
- Есть ли централизованные логи, по которым можно восстановить ход инцидента, или нужно заходить на каждый сервер?
Как читать. Ответ «от клиентов» на пятый вопрос означает, что мониторинга фактически нет, даже если установлен Prometheus. Восьмой вопрос обычно вскрывает усталость от шума: алертов много, пользы мало. Это исправляется пересмотром порогов и удалением лишнего, а не добавлением новых дашбордов.
Доступы и секреты
- Где хранятся пароли, ключи и токены: в менеджере секретов, в переменных окружения, в репозитории, в чате?
- Кто имеет доступ к рабочим серверам и базе? Список актуален? Доступ уволенных сотрудников отозван?
- Используются ли общие учётные записи, под которыми невозможно понять, кто выполнил действие?
- Включена ли двухфакторная аутентификация у облачного провайдера, в системе контроля версий и у регистратора домена?
- Когда последний раз меняли ключи и пароли, которые знают больше трёх человек?
Как читать. Секрет в репозитории — это секрет, который уже утёк, даже если репозиторий приватный: он есть в истории, в клонах на ноутбуках, в кэше CI. Тринадцатый вопрос стоит дороже, чем кажется: доступ к регистратору домена и облачной консоли — это доступ ко всему.
Релизы и CI/CD
- Как код попадает на сервер: автоматически из системы контроля версий или руками по SSH?
- Что проверяется перед выкладкой: тесты, сборка, статический анализ, проверка зависимостей?
- Сколько времени занимает откат к предыдущей версии и кто умеет его делать?
- Отличаются ли тестовое и рабочее окружения, и чем именно? Разные версии базы, разные переменные, разные версии зависимостей?
- Можно ли развернуть окружение с нуля из описания в репозитории, или сервер настраивался руками и его состояние не воспроизводимо?
Как читать. Ручная выкладка сама по себе не катастрофа для маленькой команды, но ответ на семнадцатый вопрос в этом случае почти всегда «долго и не все». Девятнадцатый вопрос напрямую связан с восстановлением после аварии: если сервер невоспроизводим, RTO определяется памятью одного инженера.
Резервные копии и восстановление
- Что копируется, как часто и куда? Копии хранятся отдельно от исходных данных?
- Когда последний раз восстанавливались из копии и сколько это заняло?
- Есть ли письменная инструкция по восстановлению, по которой это сделает человек, не настраивавший систему?
Как читать. Если на двадцать первый вопрос ответ «никогда», остальные ответы в этом блоке не имеют значения. Подробно о проверке восстановления мы писали в отдельной статье, а на странице мониторинга и восстановления описан процесс, который мы выстраиваем на сопровождении.
Расходы на облако
- Известно ли, за что именно вы платите: по сервисам, по окружениям, по проектам? Есть ли ресурсы, про которые никто не помнит, зачем они?
- Соответствуют ли выделенные ресурсы реальной нагрузке? Сервер, загруженный на пять процентов круглый год, и база, которая упирается в диск каждый вечер, — одинаково плохие признаки.
Как читать. Забытые ресурсы встречаются почти везде: тестовые стенды, снимки дисков, старые балансировщики, неиспользуемые адреса. Их удаление — самая быстрая экономия, которая не требует изменений в архитектуре.
Что исправлять первым
Список находок после такого прохода обычно длинный, и желание исправить всё сразу приводит к тому, что не исправляется ничего. Порядок, который мы используем на практике:
- То, что приведёт к потере данных. Непроверенные или отсутствующие копии, копии рядом с данными, единственный экземпляр базы без реплики. Потерянные данные не вернуть никакими деньгами.
- То, что приведёт к потере контроля. Секреты в репозитории, общие учётные записи, отсутствие двухфакторной аутентификации у провайдера и регистратора, доступы бывших сотрудников.
- То, из-за чего вы узнаете о проблеме последними. Отсутствие мониторинга ключевых показателей, алерты в никуда, логи, которые нельзя найти.
- То, что замедляет восстановление. Невоспроизводимые серверы, отсутствие инструкций, зависимость от одного человека.
- Всё остальное. Оптимизация расходов, ускорение релизов, улучшение архитектуры. Это важно, но подождёт неделю.
Внутри каждого пункта начинайте с того, что можно сделать за день. Включить двухфакторную аутентификацию, вынести копии в другое хранилище, поставить алерт на место на диске — это часы работы, а не проекты.
Что дальше
Если хотите, чтобы по этому списку прошёл инженер со стороны, с доступом только для чтения и без обязательств с вашей стороны, закажите бесплатный экспресс-аудит за 48 часов. Для глубокой проверки с анализом архитектуры, нагрузки и расходов есть полный аудит инфраструктуры с отчётом и планом работ по приоритетам.