Для меня тоже неясно в чем плюсы/минусы по сравнению с существующими подходами.
Что я услышал: есть некие компоненты, которые разворачиваются у участников, эти компоненты общаются между собой, есть эцп и прочее, чтобы в случае чего, можно было в суде решать спорные ситуации.
И чем это принципиально отличается от существующих подходов?
Ниже упоминают, что если участников будет несколько сот тысяч. Но новое решение не предназначено для сотен тысяч. Там участники обмениваются публичными ключами, и контрактами.
Опять же ниже упоминают про ускорение. Но за счет чего происходит ускорение? И почему этого ускорения нет при традиционных подходах?
Хорошо, вместо фразы регулярная проверка качества, пусть будет интеграция кода происходит хотя бы раз в день.
Все-равно это не про запрет пушить напрямую.
Строго говоря запрет напрямую пушить и ci/cd друг к другу ортогональны.
В данном случае может быть ci/cd на пул-реквесты, т.е. автосборки автособираются, дают обратную связь по качеству, люди при этом оценивают код не только с точки зрения машинного качества, но и точки зрения человеческого — оформление, понятность и прочее.
Т.е. ci/cd не про запрет пушить, а про регулярную проверку качества.
программирование и администрирование друг от друга столь же далеки, как и оба вместе от продаж
Программирование и администрирование, действительно, имеют не пересекающиеся области знаний.
Примерно так же, как условный бэкэнд и условный фронтэнд. Но прямо сейчас, мало кто скажет, давайте для развития одного продукта создадим две команды, одна — бэкэнд, вторая — фронтэнд. Для большинства уже очевидно, должна быть одна команда — с бэкэнд- и фронтэнд-скиллами.
Такая же история с программированием/администрированием. Постепенно приходит понимание, что в команде должны быть люди, которые ближе к инфраструктуре.
И примерно также, как бэкэндщики/фронтэндщики должны быть в какой-то степени взаимозаменяемы. Также и разработчики/админы, должны быть в команде в какой-то степени взаимозаменяемы. Это не означает, что любой теперь сможет с нуля playbook написать. (точно так же как не означает, что любой бэкэндщик сможет с нуля страницу сверстать). Но поправить мелкие баги/изменить конфигурацию в playbook'е — вполне может любой.
На DevOps нужно смотреть через призму развития продукта. Чтобы продукт развивался быстрее и лучше конкурентов, нужно, чтобы все критически важные умения были в команде. Например, аналитика клиентского поведения, для вас важна, но не критична — можно отдать аналитику соседней сервисной команде, отвечающей за аналитику в целом. Например, мониторинг ключевых метрик вашего приложения в онлайн для вас очень критичен, тогда мониторинг должен быть полностью у вашей команды. А мониторинг вам нужен потому что вы хотите очень оперативно реагировать на изменения нагрузки, значит вам нужны люди в команде, знакомые с инфраструктурой не понаслышке.
Ну смотрите.
Вариант А. Команда пилит продукт. На выходе получает war-ник. И отдает его команде эксплуатации, с набором инструкций, как деплоить. Всё, свою часть они сделали, все счастливы, все довольны. У второй команды свой цикл, свои правила, свои особенности. Проблемы с деплоем решает только вторая команда, пока не докажет первой, где ее косяк.
Вариант Б. Команда пилит продукт, и в том числе деплоит (и все остальное, что требуется для доставки продукта клиентам). Все проблемы, в том числе проблемы с деплоем, решает команда, одна команда. Очевидно, у команды должен быть нужный скилл по эксплуатации.
На ваш взгляд, в каком варианте в общем случае будет больше проблем? В каком варианте будет в среднем быстрее доставка?
DevOps — это просто ответ на потребность бизнеса, быстрее и качественнее релизиться. Один продукт — одна команда — один тимлидер, у которого достаточно ответственности и полномочий за весь жизненный цикл продукта.
Это одно из слабых мест подхода Configuration-as-Code.
В руках человека оказывается очень мощный инструмент, при неправильном использовании которого возможны самые печальные последствия.
Ошибка в пробелах.
В числе возможных обходных решений, генерировать конфигурацию, а не руками набивать.
Тут многие высказывают недовольство таким подходом по стимулированию (назовем это так) ит-персонала.
Организации, как и любые другие субъекты, проходят по своему жизненному циклу.
Где-то вначале своего пути, они маленькие (не в смысле роста, а в смысле развития) и незрелые. Ближе к концу, они матерые и ответственные.
На каждом этапе работает свои методы и подходы, и не работают другие.
Точно также как с человеком. Глупо мотивировать 5-летнего ребенка аналогично тому, как 40-летнего мужика.
В начале своего пути, организация может мотивировать людей упомянутым выше способом. И это реально работает. И работает хорошо.
Потом, когда организация нарастит мышцы (опять же, в смысле своего развития), поймет что лучше мотивировать через результат. Но это будет потом.
Банк делает как не надо, а Виноваты и убытки от этих неправильных действий должны нести клиенты, да?
Замените Банк на облачный хостинг, а карту на облачное хранилище.
Правильный облачный хостинг с точки зрения приватности — храним на хостинге только шифрованное. Шифруем/дешифруем только на клиентском устройстве. И главное, ключи для шифрации/дешифрации храним на отдельном физическом устройстве, пусть будет любой etoken/smartcard.
Какова вероятность коммерческого успеха такого облачного хранилища?
Можно ли сказать про другие облачные хостинги, не следующие этим принципам, что они вероломно наплевали на клиентов в погоне за личным обогащением?
будучи юр.лицом вы в праве зарегистрировать собственный OID
В случае коммерческой организации вы вольны делать все, что считаете правильным.
В случае гос.органов, наверно, более правильно, чтобы все гос услуги были в рамках единого классификатора OID. И сертификат был одним, для всех услуг (гос услуг).
Следует все таки различать декларацию, что хотим получить, и имплементацию декларации.
Куча jenkins-плагинов, это как раз имплементация. Shared Library, из той же оперы.
Тут надо договориться о том, что значит выдать продукт клиенту. Если всем клиентам сразу, то, да, сырой продукт обойдется дорого. Если 10 клиентам, с которыми налажен контакт, то риски минимальны. Как с точки зрения репутации, так и с точки зрения создания «бесполезного» продукта.
Увы и ах. Это не Сбер плохой, или любой другой условный банк.
Консьюмеризация виновата.
Абсолютному большинству клиентов банков плевать, что выполнение чего-либо в мобильном приложении, и получение СМС на этот же телефон, никак не связано с повышенной безопасностью.
С другой стороны, если банк будет делать все правильно с точки зрения безопасного поведения пользователей, то абсолютному большинству его клиентов это будет неудобно. И они сбегут в соседний банк.
Пример, Банк запускает услугу — можно онлайн снять с чужой карты нужную сумму, и закинуть ее на свою. Для этого в мобильном приложении этого банка нужно вбить все реквизиты чужой карты, включая cvv. Для любого здравомыслящего очевидно, нельзя вбивать реквизиты своей карты в чужой телефон, в чужое приложение. Для абсолютного большинства — вау, классная фишка, надо срочно пользоваться. И ведь пользуются…
Важно отличать ситуации, когда принцип работает, и когда не работает.
Например, сейчас считается, что если приватный ключ лежит только на твоем доверенном устройстве и только ты контролируешь это устройство, то никто другой не может подделать твою электронную подпись. Это принцип. Из него следует много следствий, в том числе юридически значимых. Отказавшись от этого принципа, можно серьезно срезать углы на дистанции, но у этого будет своя цена. И не все готовы эту цену платить.
Аналогично с легкими клиентами.
Легкие клиенты — означают, что вы доверяете устройству, которое вы не контролируете, хранить всю историю, и при необходимости вы просто обращаетесь к нему.
Что нарушает принцип: никто не доверяет никому.
Конечно, если отойти от этого принципа, то можно срезать некоторые углы.
Он видит все уже существующие сделки? И будет видеть все будущие сделки?
Что я услышал: есть некие компоненты, которые разворачиваются у участников, эти компоненты общаются между собой, есть эцп и прочее, чтобы в случае чего, можно было в суде решать спорные ситуации.
И чем это принципиально отличается от существующих подходов?
Ниже упоминают, что если участников будет несколько сот тысяч. Но новое решение не предназначено для сотен тысяч. Там участники обмениваются публичными ключами, и контрактами.
Опять же ниже упоминают про ускорение. Но за счет чего происходит ускорение? И почему этого ускорения нет при традиционных подходах?
Это одна из классик nvie.com/posts/a-successful-git-branching-model
И это не исключает того, что могут быть и другие классические модели.
Все-равно это не про запрет пушить напрямую.
В данном случае может быть ci/cd на пул-реквесты, т.е. автосборки автособираются, дают обратную связь по качеству, люди при этом оценивают код не только с точки зрения машинного качества, но и точки зрения человеческого — оформление, понятность и прочее.
Т.е. ci/cd не про запрет пушить, а про регулярную проверку качества.
Программирование и администрирование, действительно, имеют не пересекающиеся области знаний.
Примерно так же, как условный бэкэнд и условный фронтэнд. Но прямо сейчас, мало кто скажет, давайте для развития одного продукта создадим две команды, одна — бэкэнд, вторая — фронтэнд. Для большинства уже очевидно, должна быть одна команда — с бэкэнд- и фронтэнд-скиллами.
Такая же история с программированием/администрированием. Постепенно приходит понимание, что в команде должны быть люди, которые ближе к инфраструктуре.
И примерно также, как бэкэндщики/фронтэндщики должны быть в какой-то степени взаимозаменяемы. Также и разработчики/админы, должны быть в команде в какой-то степени взаимозаменяемы. Это не означает, что любой теперь сможет с нуля playbook написать. (точно так же как не означает, что любой бэкэндщик сможет с нуля страницу сверстать). Но поправить мелкие баги/изменить конфигурацию в playbook'е — вполне может любой.
На DevOps нужно смотреть через призму развития продукта. Чтобы продукт развивался быстрее и лучше конкурентов, нужно, чтобы все критически важные умения были в команде. Например, аналитика клиентского поведения, для вас важна, но не критична — можно отдать аналитику соседней сервисной команде, отвечающей за аналитику в целом. Например, мониторинг ключевых метрик вашего приложения в онлайн для вас очень критичен, тогда мониторинг должен быть полностью у вашей команды. А мониторинг вам нужен потому что вы хотите очень оперативно реагировать на изменения нагрузки, значит вам нужны люди в команде, знакомые с инфраструктурой не понаслышке.
Вариант А. Команда пилит продукт. На выходе получает war-ник. И отдает его команде эксплуатации, с набором инструкций, как деплоить. Всё, свою часть они сделали, все счастливы, все довольны. У второй команды свой цикл, свои правила, свои особенности. Проблемы с деплоем решает только вторая команда, пока не докажет первой, где ее косяк.
Вариант Б. Команда пилит продукт, и в том числе деплоит (и все остальное, что требуется для доставки продукта клиентам). Все проблемы, в том числе проблемы с деплоем, решает команда, одна команда. Очевидно, у команды должен быть нужный скилл по эксплуатации.
На ваш взгляд, в каком варианте в общем случае будет больше проблем? В каком варианте будет в среднем быстрее доставка?
DevOps — это просто ответ на потребность бизнеса, быстрее и качественнее релизиться. Один продукт — одна команда — один тимлидер, у которого достаточно ответственности и полномочий за весь жизненный цикл продукта.
В руках человека оказывается очень мощный инструмент, при неправильном использовании которого возможны самые печальные последствия.
Ошибка в пробелах.
В числе возможных обходных решений, генерировать конфигурацию, а не руками набивать.
Это помимо code review, и тестовых контуров.
Организации, как и любые другие субъекты, проходят по своему жизненному циклу.
Где-то вначале своего пути, они маленькие (не в смысле роста, а в смысле развития) и незрелые. Ближе к концу, они матерые и ответственные.
На каждом этапе работает свои методы и подходы, и не работают другие.
Точно также как с человеком. Глупо мотивировать 5-летнего ребенка аналогично тому, как 40-летнего мужика.
В начале своего пути, организация может мотивировать людей упомянутым выше способом. И это реально работает. И работает хорошо.
Потом, когда организация нарастит мышцы (опять же, в смысле своего развития), поймет что лучше мотивировать через результат. Но это будет потом.
Замените Банк на облачный хостинг, а карту на облачное хранилище.
Правильный облачный хостинг с точки зрения приватности — храним на хостинге только шифрованное. Шифруем/дешифруем только на клиентском устройстве. И главное, ключи для шифрации/дешифрации храним на отдельном физическом устройстве, пусть будет любой etoken/smartcard.
Какова вероятность коммерческого успеха такого облачного хранилища?
Можно ли сказать про другие облачные хостинги, не следующие этим принципам, что они вероломно наплевали на клиентов в погоне за личным обогащением?
Про второе. гугл define:consumerization.
В случае коммерческой организации вы вольны делать все, что считаете правильным.
В случае гос.органов, наверно, более правильно, чтобы все гос услуги были в рамках единого классификатора OID. И сертификат был одним, для всех услуг (гос услуг).
Куча jenkins-плагинов, это как раз имплементация. Shared Library, из той же оперы.
Еще есть старый добрый TSP
Консьюмеризация виновата.
Абсолютному большинству клиентов банков плевать, что выполнение чего-либо в мобильном приложении, и получение СМС на этот же телефон, никак не связано с повышенной безопасностью.
С другой стороны, если банк будет делать все правильно с точки зрения безопасного поведения пользователей, то абсолютному большинству его клиентов это будет неудобно. И они сбегут в соседний банк.
Пример, Банк запускает услугу — можно онлайн снять с чужой карты нужную сумму, и закинуть ее на свою. Для этого в мобильном приложении этого банка нужно вбить все реквизиты чужой карты, включая cvv. Для любого здравомыслящего очевидно, нельзя вбивать реквизиты своей карты в чужой телефон, в чужое приложение. Для абсолютного большинства — вау, классная фишка, надо срочно пользоваться. И ведь пользуются…
Например, сейчас считается, что если приватный ключ лежит только на твоем доверенном устройстве и только ты контролируешь это устройство, то никто другой не может подделать твою электронную подпись. Это принцип. Из него следует много следствий, в том числе юридически значимых. Отказавшись от этого принципа, можно серьезно срезать углы на дистанции, но у этого будет своя цена. И не все готовы эту цену платить.
Аналогично с легкими клиентами.
Что нарушает принцип: никто не доверяет никому.
Конечно, если отойти от этого принципа, то можно срезать некоторые углы.