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

Речь, конечно, о DevOpsConf. Если не вдаваться в детали, то 30 сентября и 1 октября мы проведем конференцию об объединении процессов разработки, тестирования и эксплуатации, а если вдаваться — прошу под кат.

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

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

Конференция для фанатов DevOps-подхода - 1
Читать полностью »

Если вы бывали на HighLoad++, то знаете о традиционном митапе по Go. Активисты, интересующиеся Go, занимали зал на пару часов, представляли небольшие доклады, обсуждали насущные темы, холиварили. Были на HighLoad++ и отдельные доклады по Go.

Теперь, нам кажется, что пора выходить на новый уровень, поэтому 7 октября мы проведем GolangConf. Из названия понятно, что это конференция про Go, но этого явно недостаточно.

5-6 причин прийти на GolangConf - 1

Мы готовим эту конференцию для:

  • Go-разработчиков — тех, кто уже давно сидит на Go, кому интересно обсудить новинки, поговорить о производительности и «кишках», узнать, что меняется в Go, похоливарить о дженериках, например.
  • Кроме того, поскольку Go-общество расширяется, мы ждем программистов, которые только-только переходят на Go или даже только подумывают об этом. Покажем им истории успеха, реализовавшегося с переходом на Go, или истории провала. Узнаем, что не получается, почему, какие их первые чувства, мнения, впечатления.
  • Третья категория посетителей — пользователи инструментов, написанных на Go. Это популярные в рамках Cloud Native инфраструктур: Kubernetes, Docker, Terraform, Consul и другие продукты Hashicorp. На Go-конференции гости, с одной стороны, узнают, какие у этих инструментов есть проблемы, связанные с особенностями языка, а с другой — увидят, какие в Go есть вызовы и задачи, чтобы начать, например, контрибьютить в эти проекты.

Чтобы определить, какие именно темы нужно обсудить на конференции по Go, какие проблемы и задачи важны для каждой из категорий слушателей, мы собрали Программный комитет и активистов Go-сообщества. Устроили своего рода мозговой штурм. Результатами делимся с вами и, поскольку главная наша цель — развивать сообщество, надеемся на ваш отклик. Напишите в комментариях, что нужно раскрыть полнее, что совсем неинтересно, а что именно то что нужно. Посоветуйте, например, стоит ли обсуждать особенности эксплуатации Go под Windows, а то мнения разделились.
Читать полностью »

«Нужно активнее нести DevOps в массы», — решили мы в прошлом году, провели масштабный ребрендинг RootConf и запустили DevOpsConf, как место, где инженеры смогли обсудить множество насущных проблем и посмотреть на то, что же творится вокруг, чем живут в близких областях, как выходят из похожих, но все же отличных ситуаций. Нам удалось собрать классную программу и, что еще важнее, аудиторию профессионалов, которым боли и их решения были нужны и понятны.

Что ж, не будем останавливаться на достигнутом — продолжим продвижение подхода интеграции процессов разработки, тестирования и эксплуатации уже в мае на РИТ++.

Поскольку DevOps в нашем понимании — это про объединение всех процессов разработки, то фестиваль конференций РИТ++, в котором участвуют и серверные и клиентские разработчики, и управленцы разных уровней, люди, выстраивающие бизнес-процессы, и многие другие специалисты IT, — самое место, чтобы говорить о DevOps.
Читать полностью »

Всем добрый вечер! Спешим поделиться новостью о том, что уже в феврале у нас запускается новый поток по курсу «Devops — практики и инструменты», а это значит, что пора закончить начатое и опубликовать третью часть статьи: «Почему важна SRE документация». Поехали!

Документы для управления командами SRE

Командам SRE для эффективной работы необходима надежная и доступная документация.

Сайт команды

Примечание: Вместо сайта можно использовать отдельный спейс или раздел в Confluence/Wiki.

Сайт команды важен тем, что обеспечивает координацию информации и документации, связанной с командой SRE и ее проектами. Например в Google, многие команды SRE используют g3doc (внутренняя платформа документирования Google, где доки живут в исходном коде вместе со связанным кодом), а некоторые команды используют g3doc и Google Sites: в таком случае страницы g3doc тесно связаны с кодом/деталями реализации.

Устав команды

Команды SRE должны должны поддерживать опубликованный устав, в котором описываются мотивы работы и документируется текущая вовлеченность. Устав необходим для установления идентичности, основных целей и значения команды в рамках всей компании.
Читать полностью »

image

Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса иили его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.

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

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

Вот и осталось всего ничего (то есть один день) до запуска потока курса «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 инфраструктуру. Я попросил ее рассказать о каждой книге чуть подробнее – надеюсь, читателям Хабры этот список, дополненный четырьмя еженедельными рассылками, будет полезен.
Читать полностью »


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