Разработка с учетом эксплуатации

Разработайте приложение так, чтобы группа эксплуатации получила все необходимые средства.

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

• Развертывание
• Наблюдение
• Escalation (Эскалация);
• Реагирование на инциденты
• Аудит безопасности.

Для облачных приложений особенно важны надежные механизмы ведения журнала и трассировки. Привлеките группу эксплуатации к проектированию и планированию, чтобы приложение предоставлял им данные и аналитические сведения, необходимые для успешного выполнения.

Рекомендации

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

Инструмент для мониторинга. Мониторинг позволяет понять, насколько хорошо (или плохо) работает приложение с точки зрения доступности, производительности и работоспособности. Например, мониторинг дает возможность проверить соблюдение соглашений об уровне обслуживания. Мониторинг выполняется во время обычной работы системы. Он должен быть максимально приближен к режиму реального времени, чтобы группа эксплуатации могла быстро реагировать на любые проблемы. Идеально реализованный мониторинг позволит предотвратить проблемы до того, как они приведут к критическому сбою. Дополнительные сведения см. в статье об отслеживании и диагностике.

Инструмент для анализа первопричин. Анализ первопричин — это процесс поиска основной причины ошибки. Он выполняется уже после того, как произошел сбой.

Используйте распределенную трассировку. Примените систему распределенной трассировки, охватывающую параллелизм, асинхронность и облачные масштабы. При трассировке должен использоваться идентификатор корреляции, единый для всех служб приложения. Одна операция может содержать множество вызовов к разным службам приложения. В случае сбоя такой операции идентификатор корреляции поможет найти причину сбоя.

Стандартизация журналов и метрик. Группой эксплуатации будут собираться журналы из нескольких служб, развернутых в решении. Если в каждой службе используется индивидуальный формат журнала, будет сложно или даже невозможно получить полезные сведения из таких журналов. Создайте общую схему и описания полей, например идентификатор корреляции, имя события, IP-адрес отправителя и т. д. Для отдельных служб можно создавать пользовательские схемы, которые наследуют формат базовой схемы и содержат дополнительные поля.

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

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