Рубрика «sre» - 5

Всем добрый вечер!

Вот и осталось всего ничего (то есть один день) до запуска потока курса «DevOps практики и инструменты», а значит нам надо успеть за это время довыложить оставшиеся части статьи «Почему важна SRE документация».

Продолжаем.

Документы для Онбординга Нового Сервиса

SRE проводят PRR (production readiness review, обзор готовности производства) для проверки соответствия сервиса стандартам операционной готовности, а также чтобы убедиться, что владельцы сервиса понимают, как пользоваться знаниями SRE для управления большими системами.

Сервису необходимо пройти эту проверку до запуска в продакшн. (До запуска его поддерживают не SRE, а сама команда разработки.) Цель PRR на данном этапе — убедиться, что сервис будет удовлетворять минимальным стандартам надежности на момент запуска.

Почему важна SRE документация. Ч. 2 - 1Читать полностью »

Всем добрый вечер!

Интенсивность запусков у нас меняется от месяца к месяцу. Не успели сентябрьские студенты закончить второй месяц курса «Devops — практики и инструменты», как у нас открывается следующий поток. Так что мы снова готовы делиться с вами полезными материалами по теме и ждём на не менее полезных открытых уроках.

Сегодня мы рассмотрим первую часть статьи о том как документация позволяет SRE-командам управлять новыми и существующими сервисами.

SRE (site reliability engineering, примерно переводится как “обеспечение надежности информационных систем”, специалисты этой сферы носят ту же аббревиатуру) — особая дисциплина, мышление и набор технических подходов, направленных на обеспечение безотказной работы веб-продуктов и сервисов. SRE находятся на стыке разработки ПО и системной инженерии, решают эксплутационные задачи и создают масштабируемые, надежные и эффективные решения для дизайна, сборки и запуска крупномасштабных распределенных систем.

Основные задачи SRE:

  • Мониторинг и сбор метрик — определение желаемого поведения сервиса, изучение действительного поведения сервиса и устранение различий.
  • Реагирование на чрезвычайные ситуации — обнаружение и эффективное реагирование на сбои сервиса, чтобы сохранить соответствие доступности сервиса с его SLA (service-level agreement, соглашение об уровне услуг).
  • Планирование мощностей — прогнозирование будущего спроса и обеспечение нужного количества вычислительных ресурсов в соответствующих локациях для удовлетворения этого спроса.
  • Масштабирование сервиса — предсказуемое развертывание и удаление вычислительных мощностей сервиса в дата-центре, часто как следствие планирования мощностей.
  • Управление изменениями — изменение поведения сервиса без потери его надежности.
  • Производительность — дизайн, разработка и инжиниринг, связанные с масштабированием, изоляцией, задержками, пропускной способностью и эффективностью.

Читать полностью »

Первые десять лет в Гугле я работал обычным инженером: запускал на картах общественный транспорт, улучшал поиск и отлавливал спам в ютьюбе. В какой-то момент обнаружилось, что по соседству с командами SWE (Software Engineers) существуют какие-то загадочные SRE (Site Reliability Engineers), которые живут в продакшене и всё знают про инфраструктуру, конфиги и мониторинг. Обычно они приходили к нам с непонятными графиками и настойчиво рекомендовали что-нибудь переписать в нашем сервисе, чтобы он взрывался аккуратно и по кусочкам, а не целиком и вместе со всеми соседями. Или строили какой-нибудь кусок инфраструктуры, волшебным образом решающий все наши проблемы раз и навсегда. Или сообщали, что второго релиза на этой неделе не будет, потому что один датацентр смыло ураганом, а рядом с другим хоронили лошадь и перерубили магистральный кабель. Через некоторое время стало понятно, что к этим людям можно приходить с самыми разнообразными проблемами, и уходить с решениями, найденными парой уровней абстракции ниже, чем ты ожидаешь от своего собственного продукта («вы, конечно, заплатили за нужный объем трафика, но вот здесь он у вас тупо не влезает в свитч, стоящий наверху стойки»).

В итоге мне стало интересно, как выглядит всё это SRE изнутри, и я подался в Mission Control – программу ротации, позволяющую провести полгода в роли SRE, получить ценного production-опыта и, при желании, вернуться в свою прежнюю команду делиться приобретёнными знаниями. Я вместо этого остался, как и две трети моих нынешних коллег по Video Processing SRE, тоже переквалифицировавшихся из обычных инженеров. Теперь я сам пугаю SWE непонятными графиками и эвакуирую ютьюбные видео из горящих датацентров, с перерывами на мирный созидательный кодинг. Оказалось, что за пятнадцать лет внутри Гугла выросла здоровая и эффективная SRE-организация со своими практиками, принципами и методами – но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.
Читать полностью »

Сегодняшняя тема — надежность World of Tanks Server — достаточно скользкая. Надежность игры — это trade off, потому в разработке игр все нужно делать быстро и быстро изменяться. Нагрузка на серверы большая, а пользователи склонны что-нибудь поломать просто из интереса. Левон Авакян на РИТ++ рассказал, что в Wargaming делают для обеспечения надежности.

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

Надежность World of Tanks Server - 1

О спикере: Левон Авакян работает в компании Wargaming в должности Head of WoT Game Services and Reliability и занимается проблемами надежности танкового сервера.

Читать полностью »

Что мы читали в марте: пять необходимых книг для инженеров инфраструктуры - 1

Мы в Skyeng понемногу строим свою библиотеку важных и полезных книг. Началось все с того, что своими списками в Фейсбуке поделились основатели компании (ссылки ниже), а теперь к ним присоединились и руководители направлений. В марте свой топ профессиональной литературы представила Надежда Рябцова, отвечающая за нашу IT инфраструктуру. Я попросил ее рассказать о каждой книге чуть подробнее – надеюсь, читателям Хабры этот список, дополненный четырьмя еженедельными рассылками, будет полезен.
Читать полностью »

Прим. перев.: Это перевод статьи из блога компании New Relic, где на протяжении года публикуются подобные материалы о разных ИТ-специализациях, связанных с разработкой и эксплуатацией программного обеспечения. Автором является Kevin Casey — независимый журналист и обладатель премии Azbee Award, который пишет для различных изданий и компаний (включая Red Hat).

В недавней публикации мы рассмотрели восхождение Site Reliability Engineer в современных организациях, занимающихся программным обеспечением. Но называться SRE — одно дело, а нам же хотелось бы ещё узнать, что требуется для того, чтобы преуспеть в этой должности.

7 привычек успешных Site Reliability Engineers (по версии New Relic) - 1
Инженеры New Relic в офисе компании в БарселонеЧитать полностью »

image
Часто бывает, когда что-то не работает. И никто не хочет, чтобы что-то не работало по его вине. В контексте больших инфраструктур и распределенных приложений ошибка конфигурации может быть фатальной.
В статье я покажу как правильно тестировать окружение для приложения, какие инструменты использовать, приведу примеры удачного и целесообразного тестирования.
Статья будет интересна командам, которые практикуют DevOps или SRE, ответственным Dev, и прочим хорошим людям.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js