В процессе цикла разработки, часто возникает вопрос что важнее: бизнес задачи, которые принесут выгоду в краткосрочной перспективе, или инженерные задачи, такие как правильная архитектура и стабильность, которые принесут долгосрочную выгоду. Если ваша организация задекларировала, что она внедряет девопс философию, но в процессе выясняется, что это противоречит краткосрочным бизнес целям, что если бизнес считает команды такими, которые затягивают цикл разработки, а команды чувствуют себя пожаротушителями?! В своем докладе я приведу примеры простых технических и организационных чек листов , по которым можно будет понять находятся ли цели бизнеса и команды в равновесии и как следовать девопс культуре, даже если ты один в поле воин.

1. DEVOPS OR BUSINESS. WHO WINS?

2. ОБО МНЕ
• Julia Tkachova
• Solution architect in Tradetracker
• Когда-то умела разбирать и
даже собирать системный блок,
обжимать витую пару
• Могу рассказать что-то об agile
• И еще несколько не очень-то
нужных навыков
Введите подпись.

3. ABOUT DEVOPS
• Человек или философия?
• Нужен ли бизнесу такой
подход?
• Или бизнесу нужен
пожаротушитель а философия
потом?
• Как выяснить цели бизнеса и
скоординировать их с
техническим роадмапом?
Введите подпись.

4. DEVOPS APPROACH CHECKPOINT LIST
• Все идут к одной цели
• Нет понятия «works on local»
• Вовлечение в devops backlog всех
членов команды
• Все понимают архитектуру
приложения
• Все понимают как и где зарабатывает
бизнес и как Вы им можете помочь
• Все могут оценить важность того или
иного компонента для бизнеса
Введите подпись.

5. TECHNICAL ARCHITECTURE REVIEW
CHECKLIST
• Все понимают архитектуру
приложения и как оно попадает к
реальным пользователям
• IaaC, бизнес сможет
восстановиться даже при потере
всей инфраструктуры
• Monitoring and alerting,
SLO/SLA/SLI
• Security processes
• CI/CD,стандартизация и GitFlow
or GithubFlow
Введите подпись.

6. РОЛЬ DEVOPS/SRE В КОМАНДЕ
• Даже, если сами можете решить
проблему- вовлекайте команду.
Говорить нет полезно.
• Донести важность тех или иных
подходов в разработке до
бизнеса для обеспечения
стабильности
• Не будьте только
пожаротушителем
• Feedback is a key
Введите подпись.

7. КАК ПРОДАТЬ СВОЮ ИДЕЮ
• Самая главная ценность - это
прибыль
• CV driven development
• Говорите о полезности
бизнесу, подкрепляйте
фактами из инцидентов
• Сколько мы потеряем, если не
сделаем так?
• ROI. Business language is hard.
Введите подпись.

8. DEVELOPMENT PROCESS
• Задавайте вопросы, берите на себя
ответственность говорить с бизнесом
• Обучайте команду разбираться в
инфраструктуре
• Проводите регулярный воркшопы
• Не бойтесь высказывать ваше мнение
• Вовлекайте в составление и
приоритезацию беклога на основании
собранного фидбека
• Вовлекайте в имплементацию, если
возможно
Введите подпись.

9. AGILE FRAMEWORKS
• Kanban or scrum
• Kanban не значит нет
эситмейтов и коммитмента
• Scrum не значит много
бесполезных митингов
• Kanban не по умолчанию для
инфраструктурного инженера
или команды
Введите подпись.

10. СПАСИБО
• Linkedin:
https://www.linkedin.
com/in/juliyatkachova
• Telegram: @juliatk