add some pictures and send to prod

content/post/devops.md

@@ -2,7 +2,6 @@
 title: 'О devops'
 author: ctrlok
 layout: post
-draft: true
 date: 2016-05-26
 ---
 
@@ -67,6 +66,8 @@ date: 2016-05-26
 
 Для уменьшения задержек мы сделаем команды инженеров ответственными как за новые фичи, так и за стабильность работы продукта. Потому что как одно, так и второе, – часть пользовательского опыта от использования сервиса. И фичи, и стабильность – это и есть продукт. К тому же, если надо выстроить приоритеты между стабильностью и скоростью, то лучше это делать в одной команде, где понимают, чем что чревато, чем на бесконечных совещаниях двух команд с совершенно противоположными целями.
 
+![](/images/devops/love.png)
+
 Тут внимательный читатель обратит внимание, что почти всё, чем занимался опс отдел, связано со стабильностью, и будет прав. Поэтому работа опсов должна быть вынесена в команды, которые разрабатывают и используют продукт.
 
 Я знаю, это очень громкое утверждение. Проблемы, с которыми сталкиваются при таком переходе, были описаны ещё в начале статьи, но давайте подумаем: можно ли решить эти проблемы другим путём? Что если у нас будет отдел, который при помощи автоматизации уберёт рутинные задачи и будет иметь необходимую экспертизу, чтобы делиться ею с другими командами? Одни проблемы могут быть решены обучением и совместным внедрением, а другие (в том числе и шаринг экспертизы) — скриптами. А немногое общее может стать внутренним продуктом, который эта команда будет предоставлять.
@@ -91,7 +92,11 @@ date: 2016-05-26
 
 И такая команда становится намного гибче за счёт того, что у неё появились продукты, которые она делает. Не поддержка всего на свете, а конкретные продукты, как и в других продуктовых командах, опыт которых наконец-то можно использовать. После чего становится возможным выставлять собственные приоритеты, ориентируясь на общее инженерное виденье. А остальные продуктовые команды, наоборот, приближаются к тому, как работает их код, и это достаточно благостно и отрезвляюще влияет на продукт-менеджмент и стабильность, ведь если вы отвечаете за пользовательский опыт, то обычно очень быстро находите нужную и выгодную именно вам точку между стабильностью и новыми возможностями.
 
+![](/images/devops/wow.png)
+
 Описанная выше схема помимо всего прочего стимулирует делиться знаниями и опытом вместо сосредоточения умений в одних руках и дополнительно даёт свободу там, где она необходима, решая проблему масштабирования команд: хочешь использовать тарантул, монгу, очереди, постгрю? Не надо упрашивать опсов, чтобы они этим занялись. Ставь и зарабатывай свой опыт. Но отвечаешь за это тоже ты.
 И если всё идёт правильно, то побеждают тот, кто берёт на себя ответственность, а не тот, кто лучше всех перекладывает её на других. Это ведь здорово, правда?
 
+# Послесловие
+
 Для того чтобы девопс заработал, в него надо вложить немало сил. Но кроме этого много сил надо и для поддержки. Надо постоянно учиться, постоянно искать, что можно сделать лучше, и делать это лучше. Надо думать не только о сегодняшнем дне, но и том, что будет через год. Со стороны этой общей экспертной команды надо всегда смотреть на несколько шагов вперёд и стараться облегчить жизнь другим. Надо делать продукты максимально автономными и в меру абстрактными. Такими, чтобы они подходили как можно большему количеству инженеров. Сделать так, чтобы у остальных команд было как можно меньше проблем. А другие продуктовые команды должны принять на себя ответственность за свой продукт, ответственность за опыт своих пользователей и постоянно пересматривать свой продукт со стороны этого опыта. Мы в Grammarly сделали ставку на devops. И, кстати, мы хайрим(ссылка)