Настоящий CTO: думай как технический директор - Алан Уильямсон

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

13.3.2. Внутренний мониторинг

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

Определите, какое состояние компонентов следует считать «нормой». Это поможет определить и проанализировать всплески активности или необычное использование ресурса. Если внезапно уменьшился объем используемой памяти, это может говорить о том, что какой-то процесс умер или что он работает нестабильно – запускается и тут же падает. Обращайте внимание на непонятные отклонения от нормы – рост нагрузки, не связанный с увеличением трафика от пользователей или приходом новых клиентов.

С учетом особенностей вашей системы определите критерии, на основании которых вы будете принимать решение об обновлении или расширении ваших сервисов (добавлении ресурсов для веб-серверов или баз данных) или же, наоборот, об освобождении ресурсов, которые больше не нужны. Эти метрики жизненно важны для обеспечения нормальной работы. Другой уровень мониторинга – это журналы, в которых приложения фиксируют все события во время работы. Каждое приложение генерирует такие журналы, которые могут храниться как в отдельных файлах на диске, так и в службе событий Windows или в Amazon CloudWatch. Источников данных много.

Современный способ обрабатывать все эти данные – перенаправить все журналы в централизованную службу (такую как Elasticsearch) и использовать ее для сравнения, поиска аномалий, мониторинга и оповещения. Так вы сможете не только проводить анализ всех журналов в одном месте, но и легко обнаруживать связи между разными компонентами, потому что проблемы в одном из них могут быть признаком другого, более серьезного сбоя. Классический пример: увеличение количества SQL-ошибок в веб-приложении указывает на проблемы с сервером базы данных, где долго выполняющийся запрос мог заблокировать таблицы. Такие зависимости бывает трудно обнаружить, поэтому для анализа причин проблемы придется проверять различные подсистемы.

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

Заметки с полей

Централизованное время

Для современных ОС это уже обычно не является проблемой, но все же лучше убедиться, что все системы синхронизированы и используют один и тот же часовой пояс, обычно это UTC (всемирное координированное время). Во всех операционных системах есть средства синхронизации времени, которые периодически подстраивают часы. Это очень упрощает ретроспективный анализ журналов, поскольку на единой шкале времени сразу становятся видны причинно-следственные связи.

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

13.4. Резервное копирование и восстановление

Почти все компании утверждают, что у них есть резервные копии, по крайней мере важнейших компонентов, но, как сетует Райан Берч, директор по информационным технологиям в New Harbour Capital, «выглядит очевидным, но часто забывается, что резервная копия, из которой никогда не проводилось восстановление, – это не резервная копия, а просто способ расходования хранилища, что-то, что создает иллюзию безопасности, как страховочный трос, который ни к чему не прикреплен».

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

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

• Восстановление в случае сбоя.

• Периодическая фиксация состояния для контроля соответствия требованиям.

• Использование для целей тестирования/разработки.

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

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

Необходимо делать резервное копирование не только для тех сервисов, которые вы обслуживаете самостоятельно, но и для всего, что хранится в сторонних сервисах. Например, регулярно копируйте исходный код, размещенный на GitHub или Bitbucket, в безопасное и управляемое вами место. Часто забывают и о Salesforce, особенно если он применяется в основном как облачная база данных. Если вы используете Google Диск, Office 365, Dropbox – любой сервис, в котором вы храните данные, – спросите себя, к каким последствиями приведет потеря доступа к нему или блокировка учетной записи?

Чтобы создать надежную стратегию резервного копирования и восстановления, требуется много усилий; кроме того, понадобится выполнить первое архивирование и копирование данных и настроек. Но после этого все должно работать на автопилоте, а отчеты должны регистрироваться в централизованной системе журналирования, чтобы вы получали оповещения, если резервное копирование не было выполнено или произошла какая-то ошибка.

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

13.4.1. Частота/срок хранения

Два насущных вопроса – как часто следует делать резервные копии и как долго их следует хранить. Рассмотрим каждый из них по очереди.

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

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

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

Допустим, вы узнали, что был случайно удален какой-то набор данных, но это обнаружилось