Спонсором этого поста выступил PagerDuty . Спасибо за поддержку спонсоров, которые делают возможным SitePoint!
Как и многие разработчики, я ожидаю, что вещи просто сработают … и я начинаю истерику, когда это не так! За кулисами многие технические специалисты работают над тем, чтобы интегрировать аппаратные средства, программное обеспечение и услуги в работоспособные взаимосвязанные системы. В этой статье я беру интервью у Джуда Акьяера о его обязанностях и опыте DevOps в SitePoint.
(Извините, не удержался.) Не могли бы вы рассказать нам, кто вы и чем занимаетесь для SitePoint?
Джуд Аакджер: Привет, Крейг. Не проблема — неудивительно, что я получаю это довольно часто!
Я один из разработчиков, работающих над продуктами и системами в SitePoint и Learnable. Это означает бэкэнд-программирование на Ruby и PHP, а также задачи DevOps.
CB: С какими самыми большими проблемами и проблемами вы сталкиваетесь ежедневно?
JA: Определенно сортировка сигнала по шуму. Если бы мы перепрыгивали через каждое электронное письмо с обновлением пакета и за исключением веб-сайта, мы бы никогда не сделали никакой работы!
Помимо обновлений, нам также необходимо исправлять проблемы и ошибки в коде. Неважно, насколько хорош или надежен ваш код — возникнут ошибки. Задача состоит в том, чтобы определить, какие проблемы требуют немедленного внимания, а какие могут быть рассмотрены в рамках более широкой задачи рефакторинга.
CB: Откуда вы получаете оповещения?
JA: Мы используем различные инструменты для мониторинга различных частей приложений и сервисов.
Для наших веб-сайтов на Ruby on Rails мы используем гем уведомлений ( Airbrake ), который предупреждает нас всякий раз, когда наш код вызывает исключение или возникают другие непредвиденные события. Мы также используем внешний веб-сайт мониторинга ( Wormly ), который настроен на обнаружение определенных ответов HTTP. Наконец, мы используем сервис мониторинга AWS CloudWatch, который предупреждает нас о проблемах или сбоях оборудования.
Оповещения в основном отправляются по SMS и электронной почте. Как вы можете себе представить, сообщения отправляются с разных точек зрения из многих приложений. Мы постоянно стремимся улучшить наши инструменты мониторинга.
CB: Как вы расставляете приоритеты по оповещениям? Вы определяете их значимость в зависимости от влияния на стоимость бизнеса, долгосрочной важности, сложности, того, кто громко кричит, или других факторов?
JA: Приоритеты оповещений зависят от контекста, и мы вручную определяем порядок. Очевидно, что если один из наших сайтов упал, это имеет наивысший приоритет! Другие оповещения, например, когда дисковое пространство достигает определенных уровней, включаются в задачи еженедельного просмотра и обрабатываются более непринужденно.
Многие из этих процессов осуществляются в течение ряда лет, и мы можем быстро определить, что необходимо сделать. Например, Wormly оповещения всегда важны. Airbrake сообщает о проблемах, связанных с приложением, и мы изучим частоту возникновения проблемы, чтобы решить, когда ее следует устранить.
Мы призываем наших разработчиков устранить хотя бы одну повторяющуюся ошибку в спринте. Это также позволяет нам свести к минимуму шум сообщения об ошибках.
CB: Как вы планируете мониторинг новых систем и сервисов?
JA: Мониторинг имеет множество вкусов, но его нужно учитывать с самого начала.
Во-первых, мы хотим отслеживать фактические серверы, на которых работает приложение. Поскольку мы используем AWS для развертывания, встроенная статистика CloudWatch позволяет обнаруживать такие проблемы, как неизменно высокая загрузка ЦП и памяти, нехватка дискового пространства или не отвечающие серверы.
Затем мы отслеживаем сам код программы. Инструменты сообщают о фатальных исключениях или неожиданных событиях в приложении.
Наконец, мы отслеживаем приложения, как они видны из внешнего мира. Системы мониторинга отправляют HTTP-запросы на ключевые страницы и сравнивают их с известными ответами, такими как успешные запросы, перенаправления или даже ошибки.
Все наши новые приложения и сервисы должны следовать этому процессу. Конечно, иногда что-то проскальзывает. Когда это происходит, мы пишем дополнительные тесты, чтобы обнаружить это событие в будущем. Сбой в первый раз, когда возникает проблема — это одно: у вас проблемы, если это происходит дважды!
Мы используем различные инструменты и технологии, но, естественно, наши требования меняются. Важно, чтобы инструменты росли вместе с нами.
CB: Какой совет вы бы дали кому-то из команды, которая переходит на модель DevOps?
JA: Это широкий вопрос, но в основе его лежит понимание проблем как разработчиков, так и системных администраторов. Разработчикам нужна среда, которую можно быстро создать и развернуть, чтобы они могли продолжить работу с более интересными вопросами разработки приложений. Системные администраторы хотят обеспечить создание наилучшей безопасности, конфиденциальности и масштабируемых архитектур. Есть моменты, когда эти два набора проблем конфликтуют; рекомендуется прагматичный подход.
Важно, что вы должны постоянно создавать и развертывать приложения и серверы. Ваши сценарии оркестровки и развертывания должны постоянно использоваться и совершенствоваться. Вы должны избегать систем снежинок , которые мало кто понимает или может воссоздать. В идеале, стремитесь к системам Phoenix , которые могут быть сожжены и возрождены в любой момент в команде.
Относитесь к своим серверам как к скоту, а не к домашним животным! Это придаст вам уверенности в создании новых стеков или быстром масштабировании по требованию.
CB: Спасибо, Джуд. Мы ценим все ваши усилия по поддержанию работоспособности сервисов SitePoint.com.
PagerDuty: не допускать возникновения инцидентов
Не у каждой компании есть команда экспертов, готовых наброситься на каждое предупреждение. PagerDuty может помочь управлять инцидентами, улучшить видимость и улучшить сотрудничество. Основные характеристики:
- PagerDuty быстро настраивается и интегрируется с более чем 100 системами
- мониторинг агрегируется в одном месте — все можно просматривать на одной панели
- оповещения эффективны — используйте SMS, push-уведомления, телефонные звонки, электронную почту или любой другой способ, который вам подходит
- могут быть определены правила политики эскалации — система может расставить приоритеты для вас
- Вы можете легко планировать, сотрудничать и анализировать свои системы.
Для получения дополнительной информации посетите PagerDuty.com .