Бизнес | Продукты | Разработка
Как провести ИТ-аудит компании: пошаговое руководство
«IT работает, пока не сломается» — опасная философия, которая стоит компаниям миллионы. По данным Gartner, незапланированный простой IT-систем обходится бизнесу в среднем в $5 600 в минуту. А ведь 73% инцидентов можно предотвратить регулярным аудитом.
Разбираемся, как провести комплексный IT-аудит: что проверять, какие инструменты использовать и как интерпретировать результаты.
Зачем нужен IT-аудит
Типичные ситуации, когда аудит критичен
- Перед масштабированием: Планируете рост в 2-3 раза — выдержит ли инфраструктура?
- После инцидента: Сайт лежал 4 часа — как предотвратить повторение?
- При смене команды: Ушёл ключевой разработчик — что он оставил?
- Перед инвестициями: Инвестор требует due diligence IT-активов
- Регулярно: Ежегодная проверка «здоровья» систем
Что даёт аудит
- Карта рисков: Где система может сломаться и какой ущерб это нанесёт
- Оценка технического долга: Сколько стоит «закрыть» накопленные проблемы
- План развития: Приоритизированный список улучшений
- Бенчмарки: Как ваша инфраструктура соотносится с отраслевыми стандартами
5 областей IT-аудита
1. Инфраструктура и надёжность
Что проверяем:
- Архитектура серверов и сети
- Резервирование и отказоустойчивость
- Backup и восстановление
- Мониторинг и алертинг
- Capacity planning
Ключевые метрики:
| Метрика | Хорошо | Приемлемо | Критично |
|---|---|---|---|
| Uptime | >99.9% | 99.0-99.9% | <99% |
| RTO (время восстановления) | <1 час | 1-4 часа | >4 часов |
| RPO (потеря данных) | <1 час | 1-24 часа | >24 часов |
| Утилизация серверов | 40-70% | 70-85% | >85% |
Типичные находки:
- Single point of failure — нет резервирования критичных компонентов
- Backup есть, но никогда не тестировали восстановление
- Мониторинг настроен, но алерты идут на почту, которую никто не читает
2. Безопасность
Что проверяем:
- Управление доступом и аутентификация
- Шифрование данных (в покое и в движении)
- Уязвимости (сканирование, пентест)
- Журналирование и аудит действий
- Соответствие требованиям (ФЗ-152, PCI DSS)
Ключевые метрики:
| Метрика | Хорошо | Приемлемо | Критично |
|---|---|---|---|
| Критические уязвимости | 0 | 1-3 (с планом устранения) | >3 |
| Время устранения критической уязвимости | <24 часа | 1-7 дней | >7 дней |
| % систем с MFA | 100% | 80-99% | <80% |
| Возраст последнего security review | <6 мес | 6-12 мес | >12 мес |
Типичные находки:
- Пароли в открытом виде в конфигах или репозитории
- Устаревшие версии ПО с известными уязвимостями
- Общие учётные записи для разных сотрудников
- Нет логирования входов и действий администраторов
3. Код и архитектура приложений
Что проверяем:
- Качество кода (метрики, тесты)
- Архитектурные решения
- Технический долг
- Документация
- CI/CD процессы
Ключевые метрики:
| Метрика | Хорошо | Приемлемо | Критично |
|---|---|---|---|
| Покрытие тестами | >80% | 50-80% | <50% |
| Цикломатическая сложность | <10 | 10-20 | >20 |
| Дублирование кода | <5% | 5-15% | >15% |
| Время деплоя | <30 мин | 30 мин — 2 часа | >2 часов |
Типичные находки:
- «Монолит-спагетти» — всё связано со всем, изменение одного модуля ломает другие
- Нет автотестов — каждый релиз это рулетка
- Деплой вручную — занимает полдня и требует «шамана»
4. Данные и базы данных
Что проверяем:
- Производительность запросов
- Индексация и оптимизация
- Масштабируемость
- Целостность данных
- Резервное копирование
Ключевые метрики:
| Метрика | Хорошо | Приемлемо | Критично |
|---|---|---|---|
| Время ответа 95% запросов | <100 мс | 100-500 мс | >500 мс |
| Размер БД / RAM сервера | <50% | 50-80% | >80% |
| Slow queries в день | <100 | 100-1000 | >1000 |
| Запас места на диске | >50% | 20-50% | <20% |
Типичные находки:
- Запросы без индексов — сканирование миллионов строк
- N+1 проблема — 1000 запросов вместо 2
- Нет партиционирования — таблица на 500 ГБ тормозит всё
5. Процессы и команда
Что проверяем:
- Организация работы (Agile, Kanban, etc.)
- Документирование (runbooks, wiki)
- Управление знаниями (bus factor)
- Процессы инцидент-менеджмента
- Компетенции команды
Ключевые метрики:
| Метрика | Хорошо | Приемлемо | Критично |
|---|---|---|---|
| Bus factor | ≥3 | 2 | 1 |
| Lead time (идея→прод) | <2 недели | 2-4 недели | >4 недель |
| MTTR (время восстановления) | <1 час | 1-4 часа | >4 часов |
| Документация актуальна | >80% | 50-80% | <50% |
Типичные находки:
- Bus factor = 1 — уходит один человек и система становится непонятной
- Нет runbook’ов — каждый инцидент решается «с нуля»
- Документация устарела на 3 года
Как проводить аудит: пошаговая инструкция
Шаг 1: Подготовка (1-2 дня)
- Определите scope — что входит в аудит, что нет
- Соберите доступы — к серверам, репозиториям, документации
- Запросите текущую документацию — архитектуру, схемы, регламенты
- Назначьте ответственных — кто будет отвечать на вопросы
Шаг 2: Сбор данных (3-5 дней)
Автоматический сбор:
- Сканирование уязвимостей (Nessus, OpenVAS)
- Анализ кода (SonarQube, CodeClimate)
- Профилирование БД (pg_stat_statements, slow query log)
- Мониторинг (Prometheus, Grafana)
Интервью:
- Разработчики — как устроен код, какие известные проблемы
- DevOps/SRE — как устроена инфраструктура, что ломается
- Менеджеры — какие бизнес-требования, планы роста
Шаг 3: Анализ (2-3 дня)
- Классифицируйте находки по критичности (Critical / High / Medium / Low)
- Оцените стоимость исправления каждой проблемы
- Рассчитайте риски — вероятность × ущерб
- Приоритизируйте: высокий риск + низкая стоимость = делать первым
Шаг 4: Отчёт (1-2 дня)
Структура отчёта:
- Executive Summary — для руководства, 1-2 страницы
- Ключевые риски — топ-5 проблем с оценкой ущерба
- Детальные находки — по каждой области
- Рекомендации — что делать, в каком порядке, сколько стоит
- Roadmap — план на 3-6-12 месяцев
Пример: результаты аудита e-commerce компании
Контекст
Интернет-магазин, 50 000 заказов/месяц, команда 12 разработчиков.
Ключевые находки
Критические (устранить немедленно):
| Проблема | Риск | Стоимость исправления |
|---|---|---|
| SQL injection в форме поиска | Утечка данных клиентов | 8 часов |
| Backup не тестировался 2 года | Потеря данных | 16 часов |
| Единственный сервер БД без реплики | Простой до 24 часов | 40 часов |
Высокие (устранить в течение месяца):
| Проблема | Риск | Стоимость исправления |
|---|---|---|
| Нет rate limiting на API | DDoS, перегрузка | 24 часа |
| Устаревший PHP 7.4 | Уязвимости, нет поддержки | 80 часов |
| Bus factor = 1 по платёжному модулю | Риск при уходе сотрудника | 40 часов (документация) |
ROI аудита
- Стоимость аудита: 350 000 ₽
- Предотвращённый ущерб: SQL injection мог привести к штрафу по ФЗ-152 (до 18 млн ₽) + репутационный ущерб
- Экономия: Обнаружение проблемы с backup до инцидента vs после потери данных
Когда нужен внешний аудит
Внутренний аудит подходит если:
- Есть компетентная команда с опытом
- Нужна регулярная проверка (ежеквартально)
- Ограниченный бюджет
Внешний аудит нужен если:
- Нет внутренней экспертизы
- Нужен независимый взгляд
- Требуется для инвесторов/регуляторов
- После серьёзного инцидента
- Перед крупными изменениями
Tech Audit от Virtuman
Tech Audit — комплексный аудит IT-инфраструктуры:
- Глубина: Проверяем все 5 областей (инфраструктура, безопасность, код, данные, процессы)
- Инструменты: Автоматизированное сканирование + ручной анализ
- Отчёт: Детальный документ + roadmap улучшений
- Сопровождение: Помогаем устранить критические проблемы
