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

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

Также можно заключить договоры на поддержку для ключевых библиотек или ПО с открытым исходным кодом. Многие крупные проекты (Mongo, Postgres, MySQL, Elasticsearch) имеют «коммерческие» версии, которые можно приобрести, но по сути это просто договор на поддержку для того же самого продукта. Бывают недорогие коммерческие версии, где каждый релиз задерживается на некоторое время и обновление происходит только тогда, когда выйдет несколько следующих версий основного продукта. Таким образом, вы не будете сталкиваться с детскими болезнями, которые случаются в свежих релизах (иногда к этому добавляется некоторый дополнительный функционал). Кроме того, такие версии предусматривают оповещение об обновлениях безопасности, чтобы вашей команде не приходилось следить за их появлением на сайтах.

Договоры на поддержку оборудования могут сильно различаться по стоимости и уровню обслуживания. В случае дорогого контракта оборудование будет контролироваться удаленно, при этом инженеры будут самостоятельно заменять детали еще до того, как вы заметите, что они вышли из строя. Такие договоры типичны для больших SAN (storage area network, сетей хранения данных), поскольку срок службы жестких дисков ограничен. В случае более дешевой поддержки о проблеме надо будет сообщать по телефону или электронной почте, и подрядчик вышлет вам комплектующие для самостоятельной установки. За что вы заплатите, то и получите. Не всем нужен полный набор дорогих услуг, но решать тут вам.

13.2.1. Предоставление поддержки вашим клиентам

Говоря о поддержке, стоит рассмотреть и другую сторону медали: какую поддержку вы оказываете своим клиентам, когда они сталкиваются с проблемами в работе сервисов, которые вы им предоставляете? В крупных организациях первая линия поддержки обычно подчиняется операционному директору (COO) или ИТ-директору (CIO). Сотрудники этой линии поддержки напрямую взаимодействуют с конечным пользователем и пытаются диагностировать и устранить неполадку. Если им нужна помощь, они передают информацию в технический отдел. Таким образом, хотя вы напрямую и не участвуете в поддержке конечных пользователей, вам все равно необходимо разработать процессы для предоставления своевременного ответа команде поддержки. Для этого обычно предусматривают SLA (соглашение о параметрах оказываемых услуг), где фиксируются параметры, на которые может рассчитывать конечный пользователь (см. главу 10). Обычно в SLA входит следующее:

• Доступность сервиса за определенный период; например, доступность 99,9 % за год означает, что время простоя за этот период не должно быть более 8,7 часа.

• Сроки подтверждения запроса как в рабочее, так и в нерабочее время.

• Возможность удаленного мониторинга.

• Применение обновлений, включая исправления ошибок и обновления безопасности.

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

• Возможность дополнительных работ и исправления проблем, возникших не по вине поставщика, за отдельную плату.

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

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

13.3. Мониторинг

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

13.3.1. Внешний мониторинг

Если ваш основной пользователь или клиент не является частью вашей компании, то необходимо контролировать работу сервиса с его позиции. Как бы очевидно это ни звучало, это означает, что средства мониторинга должны находиться вне вашей сети. Например, если вы используете AWS, то для мониторинга стоит использовать Azure или Google, или, по крайней мере, отдельную учетную запись AWS в другом регионе.

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

Например, вы можете просто контролировать доступность веб-страницы входа в систему. Для начала неплохо, но так вы не проверите доступность API для аутентификации клиентов. Если двинуться дальше и использовать для входа тестовую учетную запись, то вы подтвердите возможность аутентификации; однако проверяет ли это работоспособность основного сервиса? Можете ли вы запрашивать еще какие-то API, которые будут выполнять запросы (только легкие) к основной базе данных? Мы добавили всего пару дополнительных шагов, но посмотрите, насколько больше всего теперь проверяется: и сеть, и API, и база данных. Выполняйте проверку каждые 5-30 минут (в зависимости от потребностей), и, если что-то из указанного выше перестанет работать, вы очень быстро об этом узнаете.

Теперь продумайте отправку оповещений. Логично отправлять их в электронном письме, но как конкретно? Если электронная почта работает в той же сети, которая контролируется, то существует риск, что письмо не будет доставлено, потому что та же проблема, которая мешает работе сервиса, может препятствовать и отправке электронной почты. Это еще одна веская причина использовать электронную почту Google или Microsoft – независимо от того, что происходит в вашей сети, почта всегда будет доступна. Если же вы поддерживаете и используете собственный почтовый сервер, то все равно настройте для оповещений адрес не на вашем основном домене, а на бесплатном сервисе (Gmail, Yahoo и т. д.), чтобы он пересылал письма нужным людям.

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

Ручное обновление страницы состояния

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

При использовании стороннего сервиса электронной почты придерживайтесь той же схемы: создайте группу или алиас «alert», письма на который будут пересылаться всем, кому нужно. Гораздо проще управлять списком рассылки, чем отправлять письма отдельным получателям.

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