Комментарии 14
кстати, в рамках DevOps есть мантра «everything is code», которая очень хорошо трансформирует сознание процессных консультантов
Можете вот это расшифровать?
Хороший вопрос. И мне так кажется, что имеется в виду ситуация, что если консалтинг не может решить проблему, значит чтоб её решить нужно написать код.
Я считаю, что ДевОпс — это уровень выше консалтинга.
Например, если есть возможность конфигом-гуи-галочками-итд достигнуть нужного эффекта, то консталтинг просто скушает её, решит внутри себя.
И если уж консалтинг выносит проблему наверх, то без кода не обойтись.
Я считаю, что ДевОпс — это уровень выше консалтинга.
Например, если есть возможность конфигом-гуи-галочками-итд достигнуть нужного эффекта, то консталтинг просто скушает её, решит внутри себя.
И если уж консалтинг выносит проблему наверх, то без кода не обойтись.
Это значит, что всё, что вы делаете — это код. Инфраструктура — это код, документы — это код. Со всеми этими штуками нужно работать по тем же (или почти по тем) правилам, как с кодом. Версионный контроль, тестирование, релизы, приёмка и всё такое.
«everything is code» в DevOps означает что абсолютно все, чем вы манипулируете является кодом.
Это распространяется как на исходный код приложения, так и на Infrastructure as Code, к которой в свою очередь применяются те же правила как Версионирование (versioning).
На любой момент вы можете восстановить и протестировать любую версию кода (GIT ветка с вашим приложением), к которой соответствует полная топология IT архитектуры (GIT ветка ИТ инфраструктуры), на которой было установлено приложение и смоделировать возникший баг с целью его исправления.
Это распространяется как на исходный код приложения, так и на Infrastructure as Code, к которой в свою очередь применяются те же правила как Версионирование (versioning).
На любой момент вы можете восстановить и протестировать любую версию кода (GIT ветка с вашим приложением), к которой соответствует полная топология IT архитектуры (GIT ветка ИТ инфраструктуры), на которой было установлено приложение и смоделировать возникший баг с целью его исправления.
В DevOps входят к примеру, услуги по устройству процесса интеграции и автоматизированного тестирования, хостинга и техподдержки инфраструктуры и т.д и т.п Это все обеспечивается с помощью людей и программного обеспечения, которое, нужно настроить, написать, отладить, поддерживать, мигрировать и т.п. Вся эта инфраструктура имеет жизненный цикл и является такой же «dеliverable» — грубо говоря программной «плюшкой» которая каждый день выкатывается из «печи», но для разработчиков. Т.о. IT-инфраструктура для программного проекта имеет все те же свойства, которые имеет продуктивный код в продукте конечного потребителя. Это значит к ней применимы те же требования которые предьявляют к коду — качество, надежность, удобство использования и т.п… Поэтому k DevOps уместен тот же подход как к разработке программного продукта для клиента, несмотря на то, что конечный пользователь DevOps — это разработчик.
мы обворачиваем Agile с двух сторон waterfall-омПоясните это утверждение? Под водопадом вы подразумеваете последовательный процесс: бюджетирование, реализация и закрытие проекта?
Нет, под водопадом и «оборачиванием» я подразумеваю то, что в начале проекта мы делаем некую «постановку задачи» (как бы делали это в waterfall-е), а в конце — некую «приёмку результатов проекта». То есть начало и окончание проекта — как в типичной каскадной модели реализации проектов. А середина, где дополнительная постановка задачи, разработка, тестирование, уже частично эксплуатация выпущенных релизов — agile.
По мне вы немного сгущаете краски. Если мы проходим стандартные стадии проектного управления, это еще не означает, что жизненный цикл разработки продукта у нас водопадный. В принципе, проектное управление не то же самое, что водопад, и проектное управление с Agile не противоречат друг другу. За несколькими исключениями. Во-первых, традиционно принято команды собирать под проекты, как следствие, многозадачность, когда люди работают в нескольких проектах одновременно, а в Agile нужны стабильные команды, которым мы даем проекты (можно несколько). Во-вторых, длительные многомиллионные (натыкаюсь и миллиардные) проекты и Agile несовместимы или «невыносимосовместимы». То есть идет смещение фокуса на продукт (услугу, сервис и т.п. ценность), а проект становится просто упаковкой работ в рамках развития продукта, сильно теряет такой сакральный смысл, как ранее в него вкладывали.
Я не утверждаю, что использование Agile переворачивает с ног на голову проектное управление. Разумеется, многое остаётся похожим. Но всё же, некоторые коррективы необходимы. И не только в проектном управлении, но и в подходе к финансированию разработки в формате Agile. Если в waterfall-е мы финансируем скоуп, то в agile мы финансируем value, а скоуп у нас может быть очень подвижным.
Краски, возможно, немного сгущаю — но без этого не было бы дискуссии :)
Краски, возможно, немного сгущаю — но без этого не было бы дискуссии :)
Немного оффтопа для любителей F1:
1. Что за машина?
2. Гонщик?
И вопрос для самых задротов:
3. Что за трек?
1. Что за машина?
2. Гонщик?
И вопрос для самых задротов:
3. Что за трек?
Свое видение на Agile и не Agile привел (03.06.2016 23:33):
club.cnews.ru
«Разговор про Bimodal IT — ведется несколько десятилетий (хотя термин и «свеженький»). Людям же нужно что-то обсуждать годами, но „как-бы новое“.
Обсуждения, как правило, в ключе: Стабильность — качество против Гибкость-скорость изменений (внедрения). Консерватизм и выдержка против Быстрых инноваций, не проверенных временем …
Там же постоянно задаю вопрос: Есть ли: „Простой пример простого EA“?
Hewlett Packard Enterprise также любит произносить странные слова „Enterprise Architecture“ (EA). Лучше бы привели пример, пусть совсем крошечного предприятия и даже на „HPE Enterprise Maps“, но комплексный.
О проблеме запутанности — см. мои статьи на Habra.
club.cnews.ru
«Разговор про Bimodal IT — ведется несколько десятилетий (хотя термин и «свеженький»). Людям же нужно что-то обсуждать годами, но „как-бы новое“.
Обсуждения, как правило, в ключе: Стабильность — качество против Гибкость-скорость изменений (внедрения). Консерватизм и выдержка против Быстрых инноваций, не проверенных временем …
Там же постоянно задаю вопрос: Есть ли: „Простой пример простого EA“?
Hewlett Packard Enterprise также любит произносить странные слова „Enterprise Architecture“ (EA). Лучше бы привели пример, пусть совсем крошечного предприятия и даже на „HPE Enterprise Maps“, но комплексный.
О проблеме запутанности — см. мои статьи на Habra.
Once industries and professions reach a certain level of maturity, efforts arise to standardize key terminology and concepts to foster improved knowledge exchange and collaboration. When done using an Enterprise Architecture framework or method, such attempts may be termed “reference architecture” or “reference models”. Notable examples of such efforts include:
- Frameworx (eTOM), by the TM Forum
- BIAN – the Banking Industry Architecture Network
- ARTS – the work of the Association for Retail Technology Standards, an affiliate of the National Retail Federation
- The ACORD framework – an Enterprise Architecture for the insurance industry
- EMMM – the work of The Open Group Exploration, Mining, Metals & Minerals Forum
Да, я знаю. Enterprise Architecture: есть ARIS для EA, есть ARIS для TOGAF, а есть TOGAF для EA и много тому подобного. Фреймворки, философии, алхимии …
Нет только просто: „Простой пример простого EA“
Поэтому: Alchemy — forever!
Давно «эти отрасли и профессии достигли» бы «определенного уровня развития» если бы не палки в колеса алхимиков и маркетологов.
Что касается сетей, которые network.
С такими сетями такого «финта ушами» как с ЕА сделать сложно.
Сети LAN-WAN, во-первых по определению стандартизированы. Иначе они не работают, во всяком случае «большие». Во-вторых, там нет — как в ЕА и ВРМ — «бизнес-составляющей»: миссия и цели компании, постоянное совершенствование и т.п. – о чем я много потратил букв в своих статьях.
В сетях есть законы физики и математики, начиная от Котельникова и помехоустойчивого кодирования. Ничего подобного в известных мне Фреймворках ЕА неет. Пока нет Фреймворка + комплексного примера – это не инженерная дисциплина, а …
Хотя уже и «в сети» лезут разные «умники» и немецкие профессора.
Посмотрим на примере BIAN. Это же «круто»?
Есть хоть что-то рациональное в статьях про BIAN от российских банков? Что рационального, например, здесь
Часто BIAN — это когда или рядом с квадратиком «Business Strategy» дорисовывают (и соответственно, монетизируют) квадратик «Business Network» или начинают говорить, что есть некая SOA исключительно для банков. Вообще, зачем в BIAN упомянут «network»?
«Маркетинговый BIAN» мне понятен, а инженерный – нет. Покажите, что это не так. Было бы очень здорово.
Покажите на конкретном комплексном примере этот самый-самый «BIAN Service Landscape» или что там они еще «продвигают». Не обязательно на Сбербанке, покажите на условном банке из пятой сотни. Отсылать на bian.org за теорией не нужно. Нужны конкретные примеры и практика.
И про „Простой пример простого EA“ тоже не забудьте, пожалуйста.
К сожалению маркетинговый мир ИТ превзошел реальный сектор ИТ точно так же, как финансово-биржевой (виртуальный) превзошел реальный сектор экономики. Многим проще жить и зарабатывать в виртуальном мире ИТ (не путать с ИТ-направлением «виртуальная реальность»), чем в реальном.
«Нет ничего практичнее хорошей теории». Только вот такой теории очень мало.
Нет только просто: „Простой пример простого EA“
Поэтому: Alchemy — forever!
Давно «эти отрасли и профессии достигли» бы «определенного уровня развития» если бы не палки в колеса алхимиков и маркетологов.
Что касается сетей, которые network.
С такими сетями такого «финта ушами» как с ЕА сделать сложно.
Сети LAN-WAN, во-первых по определению стандартизированы. Иначе они не работают, во всяком случае «большие». Во-вторых, там нет — как в ЕА и ВРМ — «бизнес-составляющей»: миссия и цели компании, постоянное совершенствование и т.п. – о чем я много потратил букв в своих статьях.
В сетях есть законы физики и математики, начиная от Котельникова и помехоустойчивого кодирования. Ничего подобного в известных мне Фреймворках ЕА неет. Пока нет Фреймворка + комплексного примера – это не инженерная дисциплина, а …
Хотя уже и «в сети» лезут разные «умники» и немецкие профессора.
Посмотрим на примере BIAN. Это же «круто»?
Есть хоть что-то рациональное в статьях про BIAN от российских банков? Что рационального, например, здесь
Часто BIAN — это когда или рядом с квадратиком «Business Strategy» дорисовывают (и соответственно, монетизируют) квадратик «Business Network» или начинают говорить, что есть некая SOA исключительно для банков. Вообще, зачем в BIAN упомянут «network»?
«Маркетинговый BIAN» мне понятен, а инженерный – нет. Покажите, что это не так. Было бы очень здорово.
Покажите на конкретном комплексном примере этот самый-самый «BIAN Service Landscape» или что там они еще «продвигают». Не обязательно на Сбербанке, покажите на условном банке из пятой сотни. Отсылать на bian.org за теорией не нужно. Нужны конкретные примеры и практика.
И про „Простой пример простого EA“ тоже не забудьте, пожалуйста.
К сожалению маркетинговый мир ИТ превзошел реальный сектор ИТ точно так же, как финансово-биржевой (виртуальный) превзошел реальный сектор экономики. Многим проще жить и зарабатывать в виртуальном мире ИТ (не путать с ИТ-направлением «виртуальная реальность»), чем в реальном.
«Нет ничего практичнее хорошей теории». Только вот такой теории очень мало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Консалтинговые ИТ-проекты в стиле Agile?