На примере одной компании изучаем переход от деплоя раз в месяц к деплою раз в час и взгляд на DevOps со всех точек зрения. Сторона заказчика: как быстрее и дешевле решать бизнес-задачи, выкатывать новые фичи и исправлять баги. Мы расскажем и покажем как деплоить код без downtime.
Сторона разработчика: как разрабатывать и выкатывать код, не упираясь в коллег, администраторов, тестировщиков, безопасников.
Сторона администратора: как обеспечивать и контролировать работоспособность инфраструктуры, создавать окружения, предотвращать аварии, минимизируя ручной труд.
Компания вымышленная, а ситуации - настоящие.
О чём переживает директор«одной компании»
Чем заняты разработчики?
Сегодняшний клиент разборчив, избалован и нетерпелив. Он звереет, если ошибку не исправили за сутки. Он уходит к конкуренту, если тот предлагает свежие пряники.
Выкатывать фичи надо быстро, очень быстро, еще быстрее. Утром идея, вечером код, ночью релиз.
Чтобы успевать за рынком, бизнес нанимает разработчиков. И чем они заняты?
Вместо исправления багов и создания фич они решают конфликты в Git, потому что не знают, как правильно организовать работу.
Администратор не в силах им помочь, потому что для него Git — это «программерские штучки».
Рассказываем, что нужно знать о Git разработчику и администратору, чтобы исключить потерю рабочего времени.
Клиенты скандалят и уходят.
Разработчик написал код. Как тестировать? На пользователях. «Когда что-то сломается, мы сразу увидим». Меж тем клиенты, столкнувшись с багами, обрывают телефоны поддержки или молча уходят к конкурентам.
Рассказываем, как создавать тестовые среды и проводить тестирование, чтобы для пользователей ошибка в приложении стала исключительным случаем, а не суровой повседневностью.
Сколько времени фича ждет в очереди?
Фича готова. Можно релизить? Нет, нужно ждать администраторов, которые вручную создадут тестовые среды, потом вручную развернут релиз. Каждый релиз готовится месяц, и изнутри прекрасно видно, сколько тяжелой и сложной работы выполняется в эти дни. А конкуренты почему-то выкатываются ежедневно.
Рассказываем, как организовать автоматизированную выкатку и тестирование. Разработчик самостоятельно создает тестовые среды, проводит тестирование и выкатывает приложение в продакшен; десяток разработчиков делает ежедневные деплои, и новые фичи появляются у пользователя сразу по готовности.
Как жить, если ушел ключевой сотрудник?
У некоторых процессов появляется «хозяин».
Разработчик пишет компонент на своей машине, и никто в компании не может воспроизвести его dev-окружение.
Администратор настраивает базы данных, и никто в компании не знает настроек и не может воспроизвести их для тестовых сред.
Если «хозяин процесса» ушел в отпуск, заболел, уволился, коллеги молятся, чтобы в его отсутствие ничего не сломалось.
Рассказываем про Infrastructure as Code, разворачивание сред, поддержание единообразия, передачу проекта (кода, инфраструктуры) между сотрудниками, чтобы добиться независимости от конкретного исполнителя.
«Ага, мы Мстители, не Предотвратители!»
Единственный мониторинг - это тикеты от пользователей в хелпдеске. Посыпались тикеты, значит, что-то сломалось, надо чинить.
Проактивного предотвращения аварий не существует.
Чтобы посмотреть, что поломалось, разработчики заходят на серверы и читают логи, попутно пытаясь вносить изменения в продакшене.
Рассказываем про мониторинг, бюджет ошибок, SLO, метрики, чтобы проактивно находить и устранять ошибки раньше, чем на них наткнутся пользователи.
Безопасность несовместима с жизнью.
Компания озаботилась наймом специалиста по информационной безопасности. Он согласует доступы на серверы, проводит ручной пентест, одобряет деплой на продакшен.
Его работа крайне тормозит процесс, но аудитор безопасности все равно недоволен.
Рассказываем про автоматическое сканирование и подпись артефактов, что позволяет автоматизированными методами добиться серьезного уровня безопасности.
Программа находится в разработке, поэтому «история одной компании» будет незначительно меняться.
На Слёрме DevOps учимся: организовать командную работу с Git;
- автоматизировать рутинные операции;
- настраивать мониторинг и интегрировать с мессенджерами;
- разворачивать серверы, используя подход Infrastructure as Code;
- обеспечивать безопасность процессов CI.
Требования к участнику
Знание Linux на базовом уровне:
- умение работать с systemd, sudo, ip, ifconfig;
- знание, как работает сеть, основные протоколы;
- знание bash на уровне чтения скриптов;
- умение работать с консолью (автокомплит, хистори и т.д.);
- знание основных утилит в линукс (ps, grep, cat, free и т.д.).
