У нас в компании идёт процесс онбординга SRE-команды. Я зашёл во всю эту историю со стороны разработки. В процессе у меня появились мысли и инсайты, которыми я хочу поделиться с другими разработчиками. В этой статье-размышлении я говорю о том, что происходит, как происходит, и как всем дальше с этим жить.
Системные администраторы всего мира, поздравляем вас с профессиональным праздником!
У нас системных администраторов не осталось (ну почти). Однако предание о них еще свежо. В честь праздника мы подготовили этот эпос. Устраивайтесь поудобней, дорогие читатели.
В этот день мы сняли для вас тёплое ламповое видео, в котором наши сисадмины рассказали о своей работе: про то, что им интересно, что вдохновляет, какие у нас есть талисманы. Мы такие же люди как и все, конечно же, мы живем не только работой, у нас остается свободное время на различные хобби, про это мы тоже рассказали и показали.
А под катом вы найдете небольшой рассказ о нашей работе и о том, чем занимаемся.
Читать полностью »
Речь, конечно, о DevOpsConf. Если не вдаваться в детали, то 30 сентября и 1 октября мы проведем конференцию об объединении процессов разработки, тестирования и эксплуатации, а если вдаваться — прошу под кат.
В рамках DevOps-подхода все части технологического развития проекта переплетены между собой, происходят параллельно и влияют друг на друга. Особую значимость здесь приобретает создание автоматизируемых процессов разработки, которые можно менять, моделировать и тестировать в реальном времени. Это помогает моментально реагировать на изменения в рынке.
На конференции мы хотим показать, как влияет такой подход на развитие продукта. Как обеспечивается надежность и адаптивность системы для клиента. Как DevOps меняет структуру и подход компании к организации рабочего процесса.
Если вы бывали на HighLoad++, то знаете о традиционном митапе по Go. Активисты, интересующиеся Go, занимали зал на пару часов, представляли небольшие доклады, обсуждали насущные темы, холиварили. Были на HighLoad++ и отдельные доклады по Go.
Теперь, нам кажется, что пора выходить на новый уровень, поэтому 7 октября мы проведем GolangConf. Из названия понятно, что это конференция про 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 должны должны поддерживать опубликованный устав, в котором описываются мотивы работы и документируется текущая вовлеченность. Устав необходим для установления идентичности, основных целей и значения команды в рамках всей компании.
Читать полностью »
Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса иили его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Всем добрый вечер!
Вот и осталось всего ничего (то есть один день) до запуска потока курса «DevOps практики и инструменты», а значит нам надо успеть за это время довыложить оставшиеся части статьи «Почему важна SRE документация».
Продолжаем.
Документы для Онбординга Нового Сервиса
SRE проводят PRR (production readiness review, обзор готовности производства) для проверки соответствия сервиса стандартам операционной готовности, а также чтобы убедиться, что владельцы сервиса понимают, как пользоваться знаниями SRE для управления большими системами.
Сервису необходимо пройти эту проверку до запуска в продакшн. (До запуска его поддерживают не SRE, а сама команда разработки.) Цель PRR на данном этапе — убедиться, что сервис будет удовлетворять минимальным стандартам надежности на момент запуска.
Всем добрый вечер!
Интенсивность запусков у нас меняется от месяца к месяцу. Не успели сентябрьские студенты закончить второй месяц курса «Devops — практики и инструменты», как у нас открывается следующий поток. Так что мы снова готовы делиться с вами полезными материалами по теме и ждём на не менее полезных открытых уроках.
Сегодня мы рассмотрим первую часть статьи о том как документация позволяет SRE-командам управлять новыми и существующими сервисами.
SRE (site reliability engineering, примерно переводится как “обеспечение надежности информационных систем”, специалисты этой сферы носят ту же аббревиатуру) — особая дисциплина, мышление и набор технических подходов, направленных на обеспечение безотказной работы веб-продуктов и сервисов. SRE находятся на стыке разработки ПО и системной инженерии, решают эксплутационные задачи и создают масштабируемые, надежные и эффективные решения для дизайна, сборки и запуска крупномасштабных распределенных систем.
Основные задачи SRE:
