От переводчика. Продолжая серию переводов про DevOps, в этот раз хочется поговорить о том, как делать НЕ надо. Мы сталкивались с этим, каждый раз, когда приходит что-то новое, например agile. Возникают культы карго, слышаться речи, что мы особенные и у нас все не так и так далее. Так давайте же попробуем избежать этого в случае DevOps.
Итак, вы хотите стать DevOps? Хорошо, но прежде чем начать, давайте взглянем на некоторые вещи, которые вы не должны делать.
В старые добрые времена, мы просто называли их «плохие идеи», но появилась дипломатия и политкорректность, ушел «мозговой штурм» и появился «idea shower», а вместе с ним и слово «анти-паттерны».
Если «паттерн» это правильный путь, то по своей сути «анти-паттерн» является неправильным — и поэтому, чтобы не дать вам пойти неверным путем, мы составили этот список (с небольшой помощью DevOps сообщества).
Не совсем.Это философия. Это способ мышления. DevOps поддерживается процессами и инструментами. DevOps, согласно Gene Kim, опирается на 3 основных принципа, известных как «Три пути»
Первый путь подчеркивает производительность всей системы — поток создания ценности.
Второй путь говорит об уменьшении и ускорении цикла обратной связи.
Третий путь заключается в создании культуры, которая способствует постоянному обучению и взаимопониманию.
(Подробнее читайте об этом в переводе статьи «11 вещей которые нужно знать о DevOps», часть 2 и 1)
Если вы задаете этот вопрос, то вы, вероятно, работаете по какому-либо agile процессу. Неплохо. У вас есть процесс разработки программного обеспечения, который следует ценностям DevOps, но Agile не означает, что вы внедрили DevOps.
DevOps переносит agile ценности на отдел администрирования, позволяя упорядочить поток задач приходящих админам и позволяя этому потоку идти дальше до клиента, превращая задачи в ценность для конечного пользователя.
CIO: «Я хочу, чтобы перейти на DevOps в течение следующего года».
MGR: «Уже готово, мы изменили таблички на дверях отделов сегодня утром. Мы настолько круты, что теперь имеем 2 DevOps команды ».
Ну супер просто.И я уверен, у вас теперь есть много «DevOps» инженеров. Если вам повезет, они могут сидеть рядом с вами за обедом.
Продолжайте. Я вас очень прошу. Уже? Молодцы! Вы реализовали DevOps.На самом деле то, что вы только что сделали, это создали еще одну силосную башню. Теперь вы получили себе другую команду, которую нужно попытаться интегрировать в текущий процесс. Еще одна команда окруженная стенами, которые нужно ломать. Может быть, стоит вернуться назад, провести ребрендинг и создать 3 DevOps команды и стать супер классными?
DevOps не говорит о том, что нужно вырвать несколько людей из разработки и администрирования и упаковать их в новую команду. Вы должны принять и внедрить. Влить команду разработчиков в команду администрирования или наоборот. Вам нужно полностью разрушить барьеры / стены / стражу между командами и сформировать их в единое целое с общими целями и обязанностями.
Подробнее по ссылке
DevOps. Это слово, которое начинается с «Dev». Это означает, что разработка становится важнее, потому что разработка стоит на первом месте… проблемы?
DevMgr — «Э-э, мы сейчас делаем DevOps. Мои ребята должны научиться работать на продакшн».
OpsMgr — «Э-э… хорошо. Так кто же будет заниматься разработкой кода? „
Слово DevOps умное. Оно производное. Это означает, что это комбинация двух слов, с целью сформировать новое слово, которое дает новый смысл. Оно даже обладает некоторой эффективностью. Это не значит, что мы взяли слово operations и заменил его словом development. Так почему бы вам не попробовать и принять DevOps именно таким образом?
DevOps требует, чтобы обе группы использовали свои ключевые навыки. И делились тем, что должно быть общим для совместной работы. Узнайте, что должно быть изучено для улучшения. Это не значит переподготовка. Это не значит, кроссфункцилнальность (впрочем, это может быть положительным побочным эффектом). Это означает обеспечивать обратную связь и прозрачность, чтобы улучшаться.
Если вы думаете, DevOps это просто buzzword, то вы, вероятно, и “облака» используете неверно. DevOps это как медаль, которую нужно получить.
DevOps больше, чем просто клевое слово.Это состояние души. Вы должны принять его ценности, вы должны помочь другим принять его ценности и вы должны постоянно совершенствовать себя и помочь другим улучшаться для того, чтобы быть успешным. Как только вы отбросите весь свой гонор и начнете совместную работу, то сможете заставить людей думать, что «DevOps» может на самом деле звучать круто.
DevOps это как вуду.В целом получаете вашу команду разработчиков и администраторов, работающих вместе. Они что-то курят, а затем приносят в жертву курицу. После того как вы это сделали, ваша организация никогда не будет прежней. Вы сможете поставлять программное обеспечение быстрее, чем когда-либо прежде. Конфигурация будет самоуправляемой. Ваши средства развертывания станут интеллектуальными. Ваши команды разработки и администрирования познают гармонию.
Добейтесь этого… DevOps это тяжелый труд! Для большинства это требуется изменения культуры! Это одна из самых трудных вещей, которые вы когда либо пробовали добиться. Для опытных разработчиков и администраторов, с которыми вы пытаетесь это сотворить, это будет то же самое, что и встать с ног на голову. Не пытайтесь сделать это за одну ночь, иначе потерпите неудачу.
Нет! Черт возьми, нет и еще раз нет. Самого трясет от злости, что вам приходится это читать…
Позвольте мне прояснить 2 вещи.
DevOps не управляется разработкой.
DevOps не управляется администрированием.
Если вы хотите среду развиваемую разработкой, хорошо, идите и создайте такую. Только не называйте это DevOps.Поэтому что это не так.
Взгляните на эту статью как на пример.
«В DevOps, программисты это программисты.» — Точно!
«Таким же образом, в DevOps, админы это админы.» — Мы уже готовы!
«Традиционно, задачи выдачи программного обеспечения на боевой сервер являются ответственностью администраторов или команды разработчиков».
Постойте-ка…
«Администраторы создают стратегии развертывания, чтобы минимизировать время простоя и обеспечить стабильность за счет гибкости и скорости реагирования».
Да, мы вернулись на знакомые рельсы… а теперь бац!
«Управление релизами через разработку» — WTF? Ситуация становится еще хуже
«Управление релизами через разработку идет по другому пути и рассматривает, как развертывание может осуществляться так часто и легко, как это только возможно. Тем не менее, эти развертывания происходят не обязательно в production… С точки зрения процесса, непрерывная поставка имеет два больших требования: во-первых, сам процесс должен быть устойчивым за пределами разработки.Это означает, что он должна быть устойчивым, как и любой процесс, который традиционная команда администрирования может воплотить».
Нет. No. Non. Nej. Na. Nee. Nein.
Development-driven может быть процессом. Это просто не DevOps. Замена администраторов автоматизированным процессом развертывания это нонсенс. Пожалуйста, не пытайтесь повторить это дома!
Да ты такой, да ты моя умница! Но ты не настолько специальный, что не можешь стать DevOps.Бьюсь об заклад, ты самый лучший разработчик там у себя, скорость работы твоего код быстрее, чем скорость света, и, когда другие программисты видят его, они плачут от радости. Нет? Итак, ты самый удивительный Ops на планете. Если бы Чак Норрис был бы администратором, то он был бы тобой. Однако, вы и ваша организация не обладаете ни одним таким фактором, который не позволит вам внедрить DevOps.Так дайте ему у вас произойти!
Джесси Роббинс из Opscode имеет несколько хороших советов для начала работ:
И еще полезно для чтения
Ну почему вы нанимаете их? Именно поэтому — они потрясающе! Если вы так не думаете, то вам надо пристально взглянуть внутрь себя, а затем пойти и открыть реальные скрытые таланты в вашей команде.
Кто-то сказал мне недавно, что они не могли сделать DevOps, потому что «у них работают неправильные разработчики и администраторы...». Это что, у них есть разработчики, которые не могут писать код? Я подумал про себя: «В моей компании работают плохие разработчики — люди, которые не умеют программировать, они работают HR и маркетинге!"
DevOps способствует совместной работе между разработкой и администрированием.Это сотрудничество должно вырабатываться на уровне политики всей компании.
И не надо говорить, что у вас работают «не те» люди. Вы просто не умеете их готовить. Боритесь с этим.
Окей, гений. Вы обо***лись.Ну и что? Мы все это делаем. Но теперь вы хотите, чтобы ваша парни-админы встали из постели в 2 часа ночи, чтобы заняться зачисткой того, о чем они ничего не знают. Они админы, а не «очистители», как Майкл Клейтон. Ждать, пока ошибка произойдет во время развертывания, чтобы начать взаимодействие между разработчиками и админами это полный отстой.
Это слишком поздно для этой проблемы… но возможно не для следующей. У вас есть команда разработчиков и админов, которые общаются (или ругаются в 2 часа ночи) друг с другом, но по крайней мере они говорят. Держите диалог постоянным. Получите ретроспективный обзор того, что произошло, и как вы можете это исправить в будущем. Если вы столкнулись с этой ситуацией, то затем попытайтесь сохранить диалог между командами. Откройте каналы связи между разработчиками и администраторами как можно раньше. И тогда надежда еще не потеряна!
Итак, вы хотите стать DevOps? Хорошо, но прежде чем начать, давайте взглянем на некоторые вещи, которые вы не должны делать.
В старые добрые времена, мы просто называли их «плохие идеи», но появилась дипломатия и политкорректность, ушел «мозговой штурм» и появился «idea shower», а вместе с ним и слово «анти-паттерны».
Если «паттерн» это правильный путь, то по своей сути «анти-паттерн» является неправильным — и поэтому, чтобы не дать вам пойти неверным путем, мы составили этот список (с небольшой помощью DevOps сообщества).
1. DevOps это процесс
Не совсем.Это философия. Это способ мышления. DevOps поддерживается процессами и инструментами. DevOps, согласно Gene Kim, опирается на 3 основных принципа, известных как «Три пути»
Первый путь подчеркивает производительность всей системы — поток создания ценности.
Второй путь говорит об уменьшении и ускорении цикла обратной связи.
Третий путь заключается в создании культуры, которая способствует постоянному обучению и взаимопониманию.
(Подробнее читайте об этом в переводе статьи «11 вещей которые нужно знать о DevOps», часть 2 и 1)
2. Agile это тоже самое что DevOps?
Если вы задаете этот вопрос, то вы, вероятно, работаете по какому-либо agile процессу. Неплохо. У вас есть процесс разработки программного обеспечения, который следует ценностям DevOps, но Agile не означает, что вы внедрили DevOps.
DevOps переносит agile ценности на отдел администрирования, позволяя упорядочить поток задач приходящих админам и позволяя этому потоку идти дальше до клиента, превращая задачи в ценность для конечного пользователя.
3. Переименование вашей команды админов / разработчиков / кого-угодно в DevOps
CIO: «Я хочу, чтобы перейти на DevOps в течение следующего года».
MGR: «Уже готово, мы изменили таблички на дверях отделов сегодня утром. Мы настолько круты, что теперь имеем 2 DevOps команды ».
Ну супер просто.И я уверен, у вас теперь есть много «DevOps» инженеров. Если вам повезет, они могут сидеть рядом с вами за обедом.
4. Запустить отдельную DevOps команду
Продолжайте. Я вас очень прошу. Уже? Молодцы! Вы реализовали DevOps.На самом деле то, что вы только что сделали, это создали еще одну силосную башню. Теперь вы получили себе другую команду, которую нужно попытаться интегрировать в текущий процесс. Еще одна команда окруженная стенами, которые нужно ломать. Может быть, стоит вернуться назад, провести ребрендинг и создать 3 DevOps команды и стать супер классными?
DevOps не говорит о том, что нужно вырвать несколько людей из разработки и администрирования и упаковать их в новую команду. Вы должны принять и внедрить. Влить команду разработчиков в команду администрирования или наоборот. Вам нужно полностью разрушить барьеры / стены / стражу между командами и сформировать их в единое целое с общими целями и обязанностями.
Подробнее по ссылке
4. Враждебное поглощение
DevOps. Это слово, которое начинается с «Dev». Это означает, что разработка становится важнее, потому что разработка стоит на первом месте… проблемы?
DevMgr — «Э-э, мы сейчас делаем DevOps. Мои ребята должны научиться работать на продакшн».
OpsMgr — «Э-э… хорошо. Так кто же будет заниматься разработкой кода? „
Слово DevOps умное. Оно производное. Это означает, что это комбинация двух слов, с целью сформировать новое слово, которое дает новый смысл. Оно даже обладает некоторой эффективностью. Это не значит, что мы взяли слово operations и заменил его словом development. Так почему бы вам не попробовать и принять DevOps именно таким образом?
DevOps требует, чтобы обе группы использовали свои ключевые навыки. И делились тем, что должно быть общим для совместной работы. Узнайте, что должно быть изучено для улучшения. Это не значит переподготовка. Это не значит, кроссфункцилнальность (впрочем, это может быть положительным побочным эффектом). Это означает обеспечивать обратную связь и прозрачность, чтобы улучшаться.
6. DevOps это очередной buzzword
Если вы думаете, DevOps это просто buzzword, то вы, вероятно, и “облака» используете неверно. DevOps это как медаль, которую нужно получить.
DevOps больше, чем просто клевое слово.Это состояние души. Вы должны принять его ценности, вы должны помочь другим принять его ценности и вы должны постоянно совершенствовать себя и помочь другим улучшаться для того, чтобы быть успешным. Как только вы отбросите весь свой гонор и начнете совместную работу, то сможете заставить людей думать, что «DevOps» может на самом деле звучать круто.
7. Продажа DevOps как серебряной пули
DevOps это как вуду.В целом получаете вашу команду разработчиков и администраторов, работающих вместе. Они что-то курят, а затем приносят в жертву курицу. После того как вы это сделали, ваша организация никогда не будет прежней. Вы сможете поставлять программное обеспечение быстрее, чем когда-либо прежде. Конфигурация будет самоуправляемой. Ваши средства развертывания станут интеллектуальными. Ваши команды разработки и администрирования познают гармонию.
Добейтесь этого… DevOps это тяжелый труд! Для большинства это требуется изменения культуры! Это одна из самых трудных вещей, которые вы когда либо пробовали добиться. Для опытных разработчиков и администраторов, с которыми вы пытаетесь это сотворить, это будет то же самое, что и встать с ног на голову. Не пытайтесь сделать это за одну ночь, иначе потерпите неудачу.
8. DevOps означает, что разработчики управляют боевыми серверами
Нет! Черт возьми, нет и еще раз нет. Самого трясет от злости, что вам приходится это читать…
9. DevOps является управление релизами через разработку ( Development-driven release management)
Позвольте мне прояснить 2 вещи.
DevOps не управляется разработкой.
DevOps не управляется администрированием.
Если вы хотите среду развиваемую разработкой, хорошо, идите и создайте такую. Только не называйте это DevOps.Поэтому что это не так.
Взгляните на эту статью как на пример.
«В DevOps, программисты это программисты.» — Точно!
«Таким же образом, в DevOps, админы это админы.» — Мы уже готовы!
«Традиционно, задачи выдачи программного обеспечения на боевой сервер являются ответственностью администраторов или команды разработчиков».
Постойте-ка…
«Администраторы создают стратегии развертывания, чтобы минимизировать время простоя и обеспечить стабильность за счет гибкости и скорости реагирования».
Да, мы вернулись на знакомые рельсы… а теперь бац!
«Управление релизами через разработку» — WTF? Ситуация становится еще хуже
«Управление релизами через разработку идет по другому пути и рассматривает, как развертывание может осуществляться так часто и легко, как это только возможно. Тем не менее, эти развертывания происходят не обязательно в production… С точки зрения процесса, непрерывная поставка имеет два больших требования: во-первых, сам процесс должен быть устойчивым за пределами разработки.Это означает, что он должна быть устойчивым, как и любой процесс, который традиционная команда администрирования может воплотить».
Нет. No. Non. Nej. Na. Nee. Nein.
Development-driven может быть процессом. Это просто не DevOps. Замена администраторов автоматизированным процессом развертывания это нонсенс. Пожалуйста, не пытайтесь повторить это дома!
10. Мы не можем сделать DevOps — Мы Уникальные
Да ты такой, да ты моя умница! Но ты не настолько специальный, что не можешь стать DevOps.Бьюсь об заклад, ты самый лучший разработчик там у себя, скорость работы твоего код быстрее, чем скорость света, и, когда другие программисты видят его, они плачут от радости. Нет? Итак, ты самый удивительный Ops на планете. Если бы Чак Норрис был бы администратором, то он был бы тобой. Однако, вы и ваша организация не обладаете ни одним таким фактором, который не позволит вам внедрить DevOps.Так дайте ему у вас произойти!
Джесси Роббинс из Opscode имеет несколько хороших советов для начала работ:
- Начните с малого — укрепления доверия
- Создайте чемпионов
- Укрепите доверие
- Празднуйте успех
- Придумывайте традиции
И еще полезно для чтения
11. Мы не можем сделать DevOps — У нас плохие сотрудники
Ну почему вы нанимаете их? Именно поэтому — они потрясающе! Если вы так не думаете, то вам надо пристально взглянуть внутрь себя, а затем пойти и открыть реальные скрытые таланты в вашей команде.
Кто-то сказал мне недавно, что они не могли сделать DevOps, потому что «у них работают неправильные разработчики и администраторы...». Это что, у них есть разработчики, которые не могут писать код? Я подумал про себя: «В моей компании работают плохие разработчики — люди, которые не умеют программировать, они работают HR и маркетинге!"
DevOps способствует совместной работе между разработкой и администрированием.Это сотрудничество должно вырабатываться на уровне политики всей компании.
И не надо говорить, что у вас работают «не те» люди. Вы просто не умеете их готовить. Боритесь с этим.
12 Сотрудничество, когда г***о попало на вентилятор
Окей, гений. Вы обо***лись.Ну и что? Мы все это делаем. Но теперь вы хотите, чтобы ваша парни-админы встали из постели в 2 часа ночи, чтобы заняться зачисткой того, о чем они ничего не знают. Они админы, а не «очистители», как Майкл Клейтон. Ждать, пока ошибка произойдет во время развертывания, чтобы начать взаимодействие между разработчиками и админами это полный отстой.
Это слишком поздно для этой проблемы… но возможно не для следующей. У вас есть команда разработчиков и админов, которые общаются (или ругаются в 2 часа ночи) друг с другом, но по крайней мере они говорят. Держите диалог постоянным. Получите ретроспективный обзор того, что произошло, и как вы можете это исправить в будущем. Если вы столкнулись с этой ситуацией, то затем попытайтесь сохранить диалог между командами. Откройте каналы связи между разработчиками и администраторами как можно раньше. И тогда надежда еще не потеряна!
