Привет! Это RU-vid-канал московского сообщества DevOps. Тут мы выкладываем видео-записи наших встречь, доклады и прочую полезную информацию. Присоединяйтесь!
Планируемые встречи на Timepad - devops-moscow.timepad.ru FB - facebook.com/devopsmoscow VK- vk.com/devopsmoscow Telegram - t.me/devopsmoscow
ИМХО. Мне кажется, что Trunk Base Development так активно продвигается девопсами по заговору. Т.к. по сути это отвратительный вариант. Единственный плюс которого - это самый простой, быстрый и ленивый вариант - конвеер тупо льёт всё подряд безконрольно (если тесты на фичу не написали, значит и ошибки в них не будет :) ), контроль тупо на разработчике и администраторе системы - есть ли флаг, вкл его и выкл. :) Никто не проверит. Это, кхэм, простите, а с каких это пор у нас стала поставка НЕ работающих, не заверщённых и непротестированных фич в проде плюсом? :) Чисто тупо мнение ленивых разработчиков времён, когда все пилили сразу в прод без всяких там гитов и прочей лабуды.
Вот читаю комментарии и почему ни у кого не возникает вопрос о том, а как внедрить фича флаги в код, да и еще так, чтобы эта херота нормально работало и управлялась. И не менее важный момент заключается в том, что никто не говорит как не нужный код потом убирать из проекта. А то получается что гавнокода накрутили, а потом его там же и оставили, отключив его лишь неким флагом.
ну обычно на таблице завязываются где прописаны какой фича флаг его описание и статус, и просто через if завязываются на блоке коде которым нужно управлять, но как будто элегантней можно через аннотации
"SOLID нам говорит - делай объект и делай вокруг него еще и абстракцию" 🙈дети дядюшки Боба, которые пихают абстракции где нужно и где нет :) Тут наверное, если колесо было покрыто Unit Test-ом, то абстракция скорее всего уже была создана для мока и ее создание вызвано необходимостью клиента (сам Test выступает в качестве полноценного клиента кода), а не следованию принципа покрыть все интерфейсами. Советую Теплякова почитать на эту тему
Какой еще Continuous Code Review? Вы бредите) Dave Farley никогда не упоминал ни про какой Continuous Code Review, потому что он достаточно умен и опытен что бы понимать, что это полная хрень) Вместо этого, он говорит про Pair Programming с постоянной ротацией пар. Но даже он признает, что эта методика хорошо работает для новых проектов, когда много чего еще не известно, но не особо продуктивна в условиях "рутинных" тасок ввиде накатывания бизнесс логики по готовым тех процессах с устоявшейся архитектурой и код конвеншнами.
С тем, что в индустрии никто не перерабатывает, можно легко поспорить на примере Яндекса, где переработки - это скорее норма, а самая часто употребляемая руководством различного уровня фраза: "надо бежать быстрее". И я уверен, что это не единственное такое место.
Приведу в серии комментариев конспект обсуждения с моими добавлениями постфактум. Вначале я рассказываю как дошёл до жизни такой, мой путь в профессии и рабочая ситуация, позволившая выкристализоваться идеям человечной декомпозиции. В запись не вошла часть, где я рассказываю о богатом опыте общения с людьми в школьные годы. Игра в джазовом оркестре театральной студии, гастроли, выступления. Ещё я забываю упомянуть с про походы с родителями и их друзьями. Всё это формирует эмоциональный интеллект и повышенный интерес к человеческим отношениям. 21:08 Я рассказываю ключевые идеи статьи. Критерии человечной декомпозиции и контрольные вопросы для верификации варианта декомпозиции. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html 30:11 Александр Титов высказывает мысль о принципиальной разнице между физическим производством и организацией мыслительной деятельности программистов. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html 33:02 Вопрос от Андрея Александрова. О какой целостности может идти речь в мире, когда существует принципиальное разделение бэкенда и фронтенда, а так же деление на микросервисы. Стала редкостью ситуация, при которой один человек может реализовать фичу от и до. Пытаемся рассмотреть пример интеграции сервисов двух отдельных команд. Приходим к выводу, что при наличии требований к API дальнейшую работу по реализации можно декомпозировать в соответствии с принципами человечной декомпозиции, делая задачи целостными. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html 40:56 Вопросы от Андрея Важенина. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html 1. Где в статье раскрывается влияние ложного убеждения про эгоизм и алчность. В рамках трансляции я не достаточно полно отвечаю на вопрос. Я говорю, что в первую очередь мне нужен этот пункт для раскрытия мотивов движущих адептами экстремального микротаскинга. А если приходим к сбалансированной человечной декомпозиции, то это убеждение становится не релевантным. Теперь я к этому добавлю, что часто бывает жалко отдавать вкусные задачи коллеге, например, когда для целей развития персонала нужно какую-то продуктовую фичу отдать младшему разработчику, а не оставить себе, как старшему. В этом случае, действительно, нужно переступать через своё эго и жадность до задач. На этой почве могут возникать трения и конфликты интересов. Об этом есть тред комментариев к статье. habr.com/ru/post/524678/#comment_22218484 2. В ситуации, когда есть свои задачи и есть коллеги, которым нужно помогать с их задачами, как найти баланс. Я отвечаю, что по моему опыту более благодарно и эффективно бывает чаще помогать коллегам. Часто это даёт инсайты для решения собственной задачи. Бывает что какая-то идея, над которой работает коллега наводит на ценные вдохновляющие мысли о своей задаче. Или просто факт отвлечения от целенаправленной работой над своей задачей позволяет мозгу работать над ней в фоновом режиме. См. тред с продолжением.
48:00 Вопрос от Александра Титова ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html Как можно мои советы, сформулированные для ситуации с продуктовой разработкой, адекватным менеджментом и развитой инженерной культурой, можно применять в более суровых условиях? А именно, в ситуации с применением Scrum, или с менеджерами, заботящимися о краткосрочной выгоде и для выполнения своих KPI форсируют более мелкое дробление на задачи, не заботясь о долгосрочной перспективе развития продукта. Я пытаюсь рассуждать но ни к чему определённому не прихожу. Утверждаю, что советы можно применять, но прийдётся сильнее маневрировать и искать баланс между размером задачи и риском, что она окажется не целостной и некачественной в перспективе. 57:22 Вступает в обсуждение этой ситуации Никита Соболев, как представитель заказной разработки и её идейный лидер. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html Мы продолжаем устно дискуссию, начатую в треде к статье habr.com/ru/post/524678/#comment_22225044 Эту часть лучше слушать. В том числе обсуждаем вопрос о комфорте работы для разных людей. Мне комфортно работать над большими задачами, а Никите комфортно всё время записывать возникающие мелкие идеи в виде тикетов. Так никогда ничего не теряется и у всех на виду. Стимулирует обсуждения. Мне напротив нравится у себя локально записывать идеи, и только что-то более оформленное и достойное отвлечения внимания других людей выносить в комментарии к задачам или в рабочий чат. 1:07:47 Вступает ещё один участник Василий Романеев. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html Обсуждаем ситуацию. В процессе работы над некоторой задачей возникает идея необходимого рефакторинга в связанной части. Если эту идею записать у себя в блокноте, или даже в комментарии к задаче, то скорее всего информация потеряется. Подход Никиты с заведением для этого отдельной задачи этой проблемы не имеет. Я говорю, что такую важную вещь как рефакторинг связанных текущей задачей частей я скорее всего выполню сразу, до внесения новых фич, или заведу тикет на тех. долг. Но не комментарий. Далее Василий хорошо подсвечивает аспект статьи, о том, что важно знать своих сотрудников и давать им либо самим для себя декомпозировать фичи, или давать готовые уже надекомпозированные задачи кем-то другим. 1:10:25 Я подчеркиваю, что главная идея статьи предотвратить ситуацию, когда есть человек способный выполнить декомпозицию, но ему не дают этого делать по недоразумению. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html см. продолжение
1:50:57 Постепенно мы выходим на вопрос обсуждения проблемы выгорания разработчиков, от которого девлид призван защищать. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html Мы вспоминаем про две причины выгорания: 1. Сверхурочная титаническая работа из-за неистовой конкурентной борьбы бизнесов. Физический и ментальный износ. Гиперответственность за результат. Пример Windows 95 и OS/2. 2. Потеря осмысленности. При номальной нагрузке 40 часов в неделю появляется время для поиска смысла. А обнаружить смысл либо крайне сложно, ибо он очень глубоко спрятан. Ещё чаще приходит осознание остсутствия причин испытывать профессиональную гордость из-за слишком мелкого дробления задач и распыления работы по нескольким людям и слоям абстракции. Кажется, что количество отраслей, в которых доминирует первая причина выгорания со временем снижается. Но в освободившихся отраслях начинает распространяться вторая причина, то есть потеря смысла. 2:00:31 Василий Романеев приводит хороший пример ситуации выгорания из-за гиперотвественности за результат, даже если от тебя этого не требуют, как частный случай перерабатывания. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html 2:04:07 Василий Романеев задаёт уточняющие вопросы по стратегии группировки содержимого задачи по одинаковому уровню сложности, риска и неопределённости. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html Я устно отвечаю сумбурно. Попробую исправить. Мы берём задачу и смотрим всё ли в ней получает одинаковую оценку в плане риска, неопределённости и сложности. Если есть какие-то части, в которых можно встрять из-за каких-то из этих измерений, то можно попробовать выделить эти части в отдельную задачу. Цель в том, чтобы минимизировать Work In Progress. Продолжение следует...
2:20:06 Василий Романеев поднимает важный терминологический вопрос о девлидах и тимлидах. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uxXdRK9QRq0.html Выясняется, что в статье я пользуюсь термином тимлид, имея в виду девлида. Я это делаю, думая, что тимлид более распространенный термин. А термин девлид мне первый раз попался только на работе в FunBox и нигде больше. Я думал, что это какой-то внутренний термин не понятный широкой аудитории. Я всерьёз задумался о том, чтобы исправить терминологию в статье. Спасибо, Василий! Далее мы уточняем контекст о котором идёт речь в статье. Во время встречи мы не смогли подвести итог. Но я сделаю это теперь. Главный вопрос не получивший полноценного ответа был такой: > Как можно применить советы статьи, выкристализовавшиеся в тепличных условиях продуктовой B2B разработки, для более суровых условий заказной разработки или продуктовой разработки консьюмерских продуктов с высокой неопределённостью, для которых часто применяют SCRUM? Своей целью при написании статьи я считал помощь тем, кто может себе позволить человечную декомпозицию, но не делает этого лишь по недоразумению. То есть применяет распространенные шаблонные методы, лежащие на поверхности, предлагающие мельчить работу для прозрачности и утилизации ресурсов. Для всех остальных возможно использовать часть идей и дух этой статьи. То есть при любой возможности делать задачи более крупными, настолько, насколько можно себе это позволить. Не пытаться искусственно измельчать задачи, не задумываясь о негативных последствиях для исполнителей. Никита Соболев озвучил важную особенность заказной разработки, о которой я успел забыть. Заказчики всегда спрашивают, даже если всё сделано хорошо: "почему так "долго"?". С этим очень сложно бороться, особенно, если заказчики - люди бизнеса, не имеющие представления о сложности разработки программного обеспечения. Всё, что можно сделать это осознанно подходить к декомпозиции, и при любой возможности проявлять смелость и делать задачи крупнее, и отвечать на обозначены вопрос проявляя каждый раз изобретательность выдумывая причины, почему же так "долго". Не оптимизировать процесс разработки и декомпозицию под лёгкость формального ответа на вопрос о затратах, предоставляя простыню задач по 15 - 30 минут, и надеясь, что это автоматом удовлетворит заказчика. Это изменение в стратегии декомопзиции может повысить качество продукции настолько, что заказчики станут меньше задавать подобные вопросы, потому что станут понимать, что им не хочется менять вас на другого поставщика. Нужно верить в возможность радикального повышения доверия к вам, за счет качества результатов вашей работы. Я далёк от этого сегмента бизнеса и могу лишь высказывать предположения. *Мои впечатления от встречи.* Публичное обсуждение моей статьи в сообществе DevOps Moscow было новым и удивительным опытом для меня. Участники были заинтересованы, они своими вопросами и высказываниями помогали подчеркнуть все основные мысли и идеи статьи. Каких-то радикально новых идей у меня не возникло, но расширилась картина рынка разработки. Стало яснее, что не во всех сегментах мои советы могут быть применены в полном объёме. Это была очень тёплая и дружественная компания. Я счастлив! Поздравляю всех с наступающим Новым Годом!
Почему-то ни у кого не возникло три логичных вопроса: 1) Что будет если постоянно отвлекать программиста на 2-10 минутные ревью чужого кода? Обычно вы пилите фичу и вы погружены в неё, вам не хочется отвлекаться. Имхо, если программиста дёргать каждые 10 минут, то его производительность упадёт практически до нуля. Если типичная фича занимает 5-6 коммитов, то получается что каждому разработчику нужно отвлечься примерно 6 раз в час на ревью, и это ужасно. А если будет смотреть не вся команда, а только 2-3 человека, то не соблюдается то, о чем говорит автор: каждый член команды знает все изменения во всех местах (зачем это вообще?). Если в команде много человек, то по-моему это привращается в неконтролируемый ад. В свою очередь, обычные пулл реквесты (branch by feature) обеспечивают возможность нормально ревьюить всю задачу за раз. 2) Во что превращается code review, если все фичи разбиты на изменения абстракций, и еще они все перемешаны в мастере (не идут последовательно)? Тут мне кажется очевидно, что когда ревьюишь фичу, хочется видеть все относящиеся к ней измнения вместе, а не искать по миллиону разбитых и перемешанных коммитов в мастере. 3) Как можно быстро переключаться между фичами, если разрешено мержить в мастер незаконченную функциональнось? Рассмотрим пример с колёсами из доклада: я сделал фичу на половину, дошёл до пулл реквеста в котором поменял первые колёса, а вторые пока не успел. Залил в мастер. Теперь приходит PM/лид и говорит: срочно переключись на другую задачу. Ок, переключаюсь, неизвестно на сколько. Пока я её делаю, мы решили задеплоиться. Автор доклада говорит, что мастер при таком подходе всегда deploy ready. Окей, деплоим, в прод попадает машина с двумя разными колёсами. Может быть я что-то не понял) Update: Эти вопросы скорее всего разжёваны на оф сайте модели ветвления(trunkbaseddevelopment.com), но мои вопросы адресованы именно к докладу и докладчику, эти моменты как будто вообще никто не заметил
1. Палка о двух концах. Что будет, если разработчик ждет ревью своего ПРа по 2-3 дня? Берет другую задачу, начинает её делать. Его ПР смотрят, он оставляет вторую задачу возвращается к первой, отправляет правки по первой задаче, отдает на ревью снова, возвращается ко второй задаче. И так далее. А может еще и третью задачу возьмет, если вторую успеет сделать. Были в такой ситуации? Я был. И был в ситуации описанной автором. С точки зрения разработки лично для меня продуктивней иногда отвлекаться, но при этом чтобы твои ПРы не застревали. Отправил ПР, его посмотрели и ты сразу же доделываешь, либо закрываешь задачу и берешь следующую. По поводу ревью 6 раз в час - вы работали в командах, где отправляют 6 ПРа в час?)) Надуманный пример мне кажется. 2. Аргумент из разряда "зачем декомпозировать фичу, давайте всё разом бахнем". Маленькие задачи закрывать легче, чем большие. Декомпозиция всегда влечет за собой некую долю того, что ты держишь в уме "сначала я делаю а потом б и потом в". И не всегда "а", "б" и "в" выглядят понятными в отрыве от остальных шагов. Надо разговаривать с тем, кто ПР отправил, чтобы прояснить ситуацию)) Как это относится к TBD или gitflow - непонятно. 3. Если бизнес логика допускает машины с разными передними и задними колесами, то в таком случае ПР, где меняются только передние колеса допустим. Если бизнес правила не допускают разных колес то и ПР такой нельзя делать, ты в таком случае ломаешь мастер и он больше не deploy ready. Если разработчик решил закоммитить дичь, то TBD магическим способом не вылечит мастер и не сделает его deploy ready. Поговорку про то, что всё можно сломать знаете) Кстати, если логичных вопроса два, то какой из этих трех нелогичный? 😜
@@ilyaeremin4329 1. С ожиданием код ревью 2-3 дня нет проблем, всегда помню что я писал 2-3 дня назад. Ваш пример логичный, но согласитесь отвлекаться раз в 1-2 дня лучше чем раз в 15-20 минут? Вообще такие переключения с задачи на задачу это нормальная часть процесса, мне кажется. И кстати пока читал, подумал что ведь не зря крупные компании нанимают fullstack-ов и убирают ежедневные созвоны? Это как раз для того чтобы не отвлекать разработчика, он взял себе кусок работы и сделает его, без тупых отвлечений на ревью чужого кода каждые 20 минут. Ну и опять-таки, ваш пример усугубляет сам себя: вы представьте если те же самые 2-3 задачи пересекутся, и надо будет ревьить 18 ПРов (условно по 6 на каждую фичу), и вы будете переключаться между этими маленькими. Я бы назвал это чистым адом. По поводу 6 ПРов в час: да, работал, компания называется Яндекс. 2. Вот это полная бредятина сразу же. "Надо разговаривать с тем, кто ПР отправил, чтобы прояснить ситуацию))". Да, действительно, вот это очень удобно. Особенно когда коммитов 6. Да и вообще, по тому что я сейчас вижу в российском биг теке, никто не использует trunk based у себя. И даже не думает в его сторону. При этом я отлично понимаю что декомпозия это замечательная штука, но использование её здесь - явно ошибка. "Маленькие задачи закрывать легче, чем большие." А у вас цель какую задачу закрыть? Маленькую или большую? Большую. Вот и не выебывайтесь, закрывайте её у себя локально как хотите, можете декомпозировать хоть на 1000 абстракций, но только локально. Можете еще разбить всё по коммитам в ветке, будет тоже хорошо. Но скидывать по отдельному ПРу не надо, это бред. Человек который будет это смотреть будет думать типо: "а где остальной код-то, когда ждать? Пойду на перекур на 15-20 минут, а он пока еще один ПР откроет". Это просто ужас, таких ожиданий быть не должно быть. Возможно я что-то не так понял, но выглядит именно так. Пока что вообще не понимаю как всякие гуглы и прочие работают с этим (так утверждает автор). 3. Бизнес-логика чаще всего не допускает машин с разными колёсами. Часто видите на улице машины с разными колёсами? Я нет. Получается что здесь декомпозировать задачу никак. Ну и смысл тогда этого примера? Если мне придётся заливать одним ПРом изменения всех колёс, то это уже почти то же самое, что заливать всю задачу одним ПРом. Пример автора тупо не работает, он высосан из пальца. Если уж пытаешься показать что-то, то надо показывать на реальных жизнеспособных вещах. Я вот сейчас читаю это еще раз, и думаю: судя по всему автор какой-то лох который повёлся на новенькое, ну ведь нельзя было так облажаться, сказать про deploy ready и показать НЕ deploy ready пример. По поводу двух логичных вопросов добавил апдейт у первого комментария)
@@ЕгорПищальников-з9г 1. Согласен, что чем реже отвлекаешься, тем лучше. Но тут важно понимать что из этого следует. Большие ПРы -> дольше ревью. За эти 2-3 дня могут поменяться требования. И уже помимо правок по ПРу если они будут, карточка уходит на дополнительную работу. В итоге ты работаешь над двумя карточками. Что не конец света, но не самая приятная ситуация. Это нормальная ситуация для вас потому что ВЫ к ней привыкли. Что лучше: работать над одной задаче и переходить к другой или переключаться между задачами? 2-3 задачи не пересекутся при tbd, потому что ревью происходит быстро. Я завершил задачу, её посмотрели, я её смержил (либо доработал и вернул на ревью снова). ВСЁ. Я забыл про этот ПР и перешел к следующей задаче. В этом прелесть. Сколько человек было в команде яндексе, в которой вы работали? В том компоненте, над которым вы работали. Интересно откуда 6 ПРов в час. По поводу фулстека тут можно поспорить почему компании так делают, но вряд ли в первую очередь потому чтобы разработчики меньше отвлекались, скорей чтобы сократить расходы на найм. Но про митинги согласен, просто ненавижууу (сижу на одном из них и пишу вам). 2. "общаться с коллегами - бредятина" (с) Егор Пищальников 2021 😂. Если фичу можно разбить и отправить в прод часть и это не помешает бизнесу - так и нужно делать. Чем чаще ты интегрируешь код в мастер, тем проще каждая интеграция, тем проще понять что пошло не так. Вас же не смущает, что прилетают правки по фичам, которые уже в проде и вы работаете над ними. В чем проблема сделать то же самое, но разбить её самостоятельно не нарушая бизнес требований? Опять же, вы пишете, что у того, кто смотрит ПР будет возникать вопрос "когда ждать следующий ПР". Его не надо ждать. Каждый ПР может быть смержен в мастер и забыт. То, что ПРы маленькие, не означает что в одном ПРе я коммичу "@уй пи3@а", а во втором "джигурда". Конечно ПРы должны иметь смысл в отрыве друг от друга. Забейте вы про карточки, которые вам создают менеджеры, они без понятия как пишется код и как лучше менегерить ваш транк. 3. Пример про колеса абстрактный, такой вы занудный)) Но, если вы уж полезли в подробности, то а. Согласно пдд на разные оси авто допускается установка разных шин (а значит колес). б. Некоторые авто с идут с разными колесами на осях с ЗАВОДА. в. Разные колеса не рекомендуются на полноприводных авто. Быстрый гугл говорит, что меньше половины авто в России полноприводные. Получается в большинстве случаев, если брать Россию, бизнес логика допускает разные колеса на оси, Раз уж взялись утверждаете что-то, не палите наобум)) Обратно к коду... Я уже выше писал, разница большими ПРами и маленькими, чтобы интегрировать ВАШИ изменения с мастером как можно чаще. Если что-то сломается вы узнаете это раньше. Смысл тут есть даже в примере этими колесами. Когда ты создаешь абстракции вокруг функционала, чтобы потом поменять реализацию и выкатываешь эти изменения, то так ты можешь проверить конкретно эти изменения. Не появилось новых ошибок в проде = ты молодец, рефактор у тебя действительно рефактор. Это будет минус одна вещь, на которую придется задумчиво смотреть в случае если в проде будет косяк. Можно копить изменения в одном ПРе и разом мержить, то это больше тестирования, больше мест, где что-то могло сломаться. Если задача дробится сильней, то почему нет? Я не говорю, что это надо делать всегда, но если вместо задачи на 5 дней, ты можешь сделать 3 задачи поменьше, то это может иметь смысл. Конечно мало смысла разбивать задачу на пару часов еще сильней, сама декомпозиция займет может занять больше времени. Короче смысл именно в том, чтобы избежать долгоживущих веток и всех неудобств, которые они с собой несут (мерж конфликты, более сложная интеграция в мастер, долгий ревью).
У записи всяких штук есть очень простой плюс: ты осознаешь то, что записал. Этого бывает достаточно чтобы что-то изменить (но не всегда). Продвинешься ли глубже или нет - это другой вопрос. Также см фрирайтинг.
DevOps -- это же в том числе и про качественное взаимодействие с людьми, которое помогает лучше работать вместе. А выгорание -- частая проблема, которая очень сильно сказывается на работе. Если мы смотрим отчет DORA, то там много внимания уделяется психологической среде в коллективах и состоянию людей.
Спасибо! Терпеть не могу сухих докладчиков) Очень помогла бы ссылочка на архив примеров кода. Фоткал на мобилу - рекогнайзер не выдает валидный питон-код(
здесь diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/ написано, почему плохо хранить секреты в переменных окружения хранить секреты в файлах ещё более опасно, даже если это удобно для разработчиков
@@vadimosipov2147 наши приложения напрямую ходят в vault за своими секретами чтобы это было удобно, проверяем ENV['MY_SECRET'] и если его нет, то идём в vault - это подходит для заглушки в development (пишем в файл .env переменные) после получения секрета храним в памяти его значение длительностью его ttl минусы в таком подходе в том, что как Сергей сказал в докладе, этот подход обязывает разработчиков знать vault api чтобы работать с ним напрямую и также нужен токен для доступа в vault токен добывать приходится с помощью sidecar контейнера, после чего записывать в (emptyDir.medium: Memory) volume , а затем приложение забирает этот токен - эта схема Сергеем описана
Хотел бы раскрытый ответ комментатора от сбербанк технологии. Статьёй или картинкой, а то похоже человек этого достаточно отведал, может даже собаку съел, но на слух сложно все понять и получить картину видения.
Сообщение Игоря информативное, спасибо. Точно полезно освещение публикационной активности и освещение маркетинговой активности. Что не хватило. Четкости. Все таки «методология» и «набор практик» это разные образования, поэтому само сопоставление отчасти сомнительно - SRE и DEVOPS. Методология - это проблемно ориентированная область знания и программа работ. Как была поставлена проблемная область DEVOPS? Про это ничего не было сказано (наверное задачи такой не было). Если SRE не методология, а спектр практик и инструментов, то это образование другого уровня совсем. Где узнать отпроблемной области DEVOPS? Подскажите, пожалуйста.
Михаил, спасибо за обратную связь. Я попробую добавить контекста, я готовил этот доклад для аудитории митапов DevOps Moscow, поэтому исходил из того что они уже знают все про DevOps, а вот про SRE мы до этого не говорили. Дать хорошее определение DevOps и SRE мне сложно, в индустрии еще не сформировался такой ответ. Я бы смотрел на тех кто сейчас развивает и продвигает DevOps и SRE, их книги и публикации - по DevOps это книги DevOps Handbook и Accelerate, по SRE - книги SRE и SRE workbook. Исходя из них основные проблемные области DevOps - улучшение взаимодействия команд, ускорение процесса поставки и быстрое получение обратной связи.
