GG
Повторюсь, что "менять" !~ увольнять, скорее проводить работу по изменению сознания
Size: a a a
2019 November 24
GG
Но если есть сопротивление, то можно его сломить административно и выгнать их на мороз
V
Повторюсь, что "менять" !~ увольнять, скорее проводить работу по изменению сознания
Да. Строить культуру и менять mindset
k
А не посоветуете литературу по этому делу? Я хоть и секур, но коли уж взялся, то надо бы закончить
V
А не посоветуете литературу по этому делу? Я хоть и секур, но коли уж взялся, то надо бы закончить
Я бы посоветовал начать, если прям начать начать, то с "Руководство по DevOps", желтая такая. Ее я переводил даже и сейчас снова перечитываю. Обзор/саммари позже сделаю.
А после нее можно "Безопасный DevOps / Securing DevOps", думаю. Её ещё не читал, но слышал хорошее. но может @rusdacent / @Nklya скажет что как/дополнят.
Поделишься мнением, @bhavenger , как будет минутка?
А после нее можно "Безопасный DevOps / Securing DevOps", думаю. Её ещё не читал, но слышал хорошее. но может @rusdacent / @Nklya скажет что как/дополнят.
Поделишься мнением, @bhavenger , как будет минутка?
VK
По хорошему в каждой должно быть минимум по 1 эксперту
Думаю, здесь подходит вариант с "платформенной командой". Выделяем безопасников в отдельную команду которая готовит тулы для всех продуктовых команд.
Иначе в каждой команде нужен разраб, qa, ops, dba, безопасник, потом добавятся бизнес аналитик, гендиректор, уборщица. Чтобы совсем self-contained
Иначе в каждой команде нужен разраб, qa, ops, dba, безопасник, потом добавятся бизнес аналитик, гендиректор, уборщица. Чтобы совсем self-contained
GG
Думаю, здесь подходит вариант с "платформенной командой". Выделяем безопасников в отдельную команду которая готовит тулы для всех продуктовых команд.
Иначе в каждой команде нужен разраб, qa, ops, dba, безопасник, потом добавятся бизнес аналитик, гендиректор, уборщица. Чтобы совсем self-contained
Иначе в каждой команде нужен разраб, qa, ops, dba, безопасник, потом добавятся бизнес аналитик, гендиректор, уборщица. Чтобы совсем self-contained
есть проблема.
GG
каждый проект - он в каком-то смысле уникален. Поэтому платформенная команда может легко стать узким местом, либо мы с огромными усилиями делаем все in-house разработкой со своими внутренними велосипедами (но такое могут позволить себе только гиганты)
GG
т.е. я к чему - должен быть некий баланс между специализацией-уникальностью и общими тулами для всей компании
GG
вариант с отдельной командой 'devops-инженеров' - 100%, что не работает.
VK
Я в безопасности профан. Чем так уникальны проекты, что для них невозможно использовать примерно одни и те же инструменты безопасности?
GG
Я в безопасности профан. Чем так уникальны проекты, что для них невозможно использовать примерно одни и те же инструменты безопасности?
ну, инструменты должны быть слишком генерализованы. Но как пример.
GG
большой энтерпрайз. 10 продуктов
GG
1 - на питоне, 2 - на голаген, 3 -на джава - maven, 4- на джава -gradle
GG
еще есть хрен знает сколько мобильных приложений на самых разных фреймворках
GG
где-то сбоку-припеку маячит разработка на C#, которую сделали подрядчики
GG
и в том же духе
GG
ах, да - обязательно есть еще какой-нибудь хадупчик, поверх которого бегают ETL-spark джобики
VK
вариант с отдельной командой 'devops-инженеров' - 100%, что не работает.
Смотря что считать отдельной командой "devops инженеров". Рекомендую книгу Team Topologies. В ней выделяют 4 типа команд и 3 типа взаимодействия. И в этой парадигме есть две команды "devops инженеров". Первая - платформенная команда которая предоставляет тулы, в пределе это AWS, GCP или Heroku. Вторая - фасилитирующая команда которая помогает овладеть этими тулами и построить процессы
GG
> Первая - платформенная команда которая предоставляет тулы, в пределе это AWS, GCP или Heroku.
это сервис и любой продакт имеет право не пользоваться этим внутренним сервисом, а, например, размещаться во внешнем облаке
это сервис и любой продакт имеет право не пользоваться этим внутренним сервисом, а, например, размещаться во внешнем облаке