Комментарии 8
Амазон можно рассматривать как модель ролей DevOps, то есть то, что у них продается, можно вырастить у себя внутри.
очень громко сказано
Раньше было: Хуяк-хуяк и в продакшн.
Теперь: Хуяк-хуяк и в контейнер.
Теперь: Хуяк-хуяк и в контейнер.
Давайте назовем эту проблему DevOps.DevOps — это решение проблемы
Ничего себе как вы ловко подменяете термины.
В тексте огромное количество спорных утверждений, которые каждый продукт и команда может оспаривать до хрипоты.
Т2М важнейший KPI? Уверены?
Есть объективное наблюдения, что многим командам очень тяжко добиться чего-то вменяемого от других команд с другими KPI.
Второе объективное наблюдение, что своя инфра ни разу не считается (крайне тяжко) по затратам и способна пожирать любые объемы ресурсов.
Вертикальные команды (DevOps) на гибридных ОпенШифт, АВС, Хероку кластерах возможно быстрей и возможно дешевле, но главное их ожидание, что они лучше обсчитываются.
Т2М важнейший KPI? Уверены?
Есть объективное наблюдения, что многим командам очень тяжко добиться чего-то вменяемого от других команд с другими KPI.
Второе объективное наблюдение, что своя инфра ни разу не считается (крайне тяжко) по затратам и способна пожирать любые объемы ресурсов.
Вертикальные команды (DevOps) на гибридных ОпенШифт, АВС, Хероку кластерах возможно быстрей и возможно дешевле, но главное их ожидание, что они лучше обсчитываются.
Какая гадость — эта ваша continuous delivery!
Пока Продукт — это три с половиной кнопки и вы раз в 11 секунд их двигаете на пару пикселей влево вправо — это еще как то можно терепть.
Но когда речь заходит о чем то крупном и комплексном, то вот эти вот ваши continuous delivery выливаются в 100500 проблем для эскплуатации. Не успели к одному хуяк-хуяку привыкнуть и как-то научиться с ним жить, как уже новый хуяк-хуяк все переиначил.
А уж о хроническом отсутствии нормальной документации и говорить не приходится. Оно и понятно — зачем документацию писать, есть она раз в 11 секунд устаревает.
Мерзотный этот ваш Agile и continuous delivery тудаже!
Пока Продукт — это три с половиной кнопки и вы раз в 11 секунд их двигаете на пару пикселей влево вправо — это еще как то можно терепть.
Но когда речь заходит о чем то крупном и комплексном, то вот эти вот ваши continuous delivery выливаются в 100500 проблем для эскплуатации. Не успели к одному хуяк-хуяку привыкнуть и как-то научиться с ним жить, как уже новый хуяк-хуяк все переиначил.
А уж о хроническом отсутствии нормальной документации и говорить не приходится. Оно и понятно — зачем документацию писать, есть она раз в 11 секунд устаревает.
Мерзотный этот ваш Agile и continuous delivery тудаже!
Спасибо за расшифровку, очень многое сказано правильно, но хотелось бы прокомментировать некоторые спорные моменты.
Было бы кстати очень полезно всем если бы кто-то описал как практически осуществлять Canary Releases (канареечные релизы) для стандартных стэков AWS/Kubernetes, Java/NodeJS/Python/etc..., получать метрики, делать выводы о стабильности релиза. Тут одной микросервисной инфраструктурой не обойдешься.
- Digital. DevOps это лишь часть Digital трансформации. И в первую очередь эта трансформация начинаться должна не в ИТ отделах, которые по хорошему не против изменений и чего-нибудь нового, а в управлении проектами и «в мозгу» у заказчика продукта. Так что Agile нужно там внедрять в первую очередь. А DevOps и остальные микросервисы сами «подъедут» когда заказчик поймет что Waterfall не работает, что изменения нужно делать постепенно, что продуктовая команда это ИТ и бизнес как единое целое.
- Системный администратор/программист как DevOps инженер. Дисциплина DevOps выросла из концепции Infrastructure as a code (инфраструктура, описанная декларативной — в настройках, скриптах, коде, конфигурации). К сожалению часто сисадмины горят желанием что-нибудь быстро установить. Но установить это только часть жизненного цикла. А для правильного DevOps нужно делать по другому. Можно и нужно нанимать системных администраторов на роль DevOps, но им нужно помогать поменять мышление и иногда это может быть трудно.
- Амазон реально деплоится раз в 11 секунд. Это не так конечно. Амазон это множество продуктов, слабо связанных между собой. Речь о том, что для ВСЕГО Амазона релиз новой версии какого-либо продукта в промышленную эксплуатацию происходит каждые 11 секунд. Это довольно реальная цифра если учесть что продуктов сотни и команд тоже много. Вот исходное обсуждение.
- Термин DevOps. Как следует из названия DevOps это объединение разработчиков и службы эксплуатации в единую команду, призванную решать не только проблему Time2market, но и общей надежности, скорости работы и качества продукта. При этом нужно в первую очередь определить что ответственность за качество продукта и его работу лежит на всех членах группы, а не на «сисадминах». И обратная связь от эксплуатации к разработчикам на предмет улучшения инфраструктуры и, возможно, внесения изменений в код не менее важна чем новые «фичи» внедряемые в срочном порядке. Infrastructure as a code помогает этого достичь.
- Команда. Важно чтобы не только DevOps инженерые понимали как оно работает в промышленной эксплутации но и разработчики. Технически помогает этого достичь концепция Dev/Prod parity — когда каждый (личный) стэнд разработчика это маленький промышленный контур и настройки промышленной версии отличаются от настроек разработчика только несколькими конфигурационными файлами. Можно и дальше цитировать 12 факторов но лучше почитать первоисточник.
- Релизы раз в неделю. Есть пример из жизни когда большая, сложная система в очень крупной организации выкладывалась 2 раза, а иногда и 3 раза в неделю. И было это достигнуто только лишь потому, что разработкой и эксплутацией системы занималась одна и таже команда людей. Когда речь зашла о разделении этих обязанностей по разным отделам то даже не предполагалась такая частота релизов. Раз в неделю да и то со скрипом. Потому что при разделении у всех получаются разные цели (и KPI если уж на то пошло).
Было бы кстати очень полезно всем если бы кто-то описал как практически осуществлять Canary Releases (канареечные релизы) для стандартных стэков AWS/Kubernetes, Java/NodeJS/Python/etc..., получать метрики, делать выводы о стабильности релиза. Тут одной микросервисной инфраструктурой не обойдешься.
Спасибо за статью, очень информативно. К вопросу о том, кто такой DevOps-ниженер, это скорее два в одном — программист + сисадмин.
Я бы даже скорее поручил эту работу программисту чем сисадмину
По крайней мере в компании, в которой я работаю, пайплайн собирали и настраивали программисты, ориетируясь на собственные нужды и особенности архитектуры проекта
Я бы даже скорее поручил эту работу программисту чем сисадмину
По крайней мере в компании, в которой я работаю, пайплайн собирали и настраивали программисты, ориетируясь на собственные нужды и особенности архитектуры проекта
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Мифы о DevOps