Спасибо за комментарий и вопросы)
icinga — это из блока «так исторически сложилось», она появилась задолго до миграции в k8s и команда devops предпочла её как сравнительно простой инструмент для нотификаций.
Так что сервисы высыпают свои данные в prometheus либо он забирает их, а icinga уже наводит панику.
Про «long-term»: для этого используется ceph, проблем не испытываем уже очень давно.
По жизненному циклу метрик и корректировке вопрос отличный, но на моей памяти такого опыта не было: процесс создания новых метрик проходит такой же code review, как и любые другие изменения в коде, и если есть сомнения по наименованию, то они решаются до ввода в прод. Поэтому изменения почти всегда относятся к двум типам: правка трешхолдов в icinga (warning / alert / critical) и удаление метрики в случае если она утратила смысл.
Если все пришли послушать одного/двух спикеров, то количество людей слабо влияет на продолжительность, а остатки Q&A всегда можно вынести в кулуары по аналогии с выступлениями на конференциях.
То есть у ситуационных встреч обычно есть понятная тема, список вопросов и в итоге это доклад на 30-40 минут + 20 минут на вопросы и ответы.
У регулярных кранчей по сути формат обычной встречи в календаре: что влезло то и обсудили, но приветствуется наличие заранее составленного плана. Это же касается и прочих встреч вроде ретро и 1-на-1 лидов с разработчиками: если есть регулярная встреча и для неё нет понятного списка топиков, то она может пройти впустую.
Красивого ответа на этот вопрос нет, но есть несколько направлений.
1. Упоминание необходимости появления артефакта в Confluence прямо в definition of done задачи. Тут, кажется, понятно какие будут последствия.
2. Документация силами QA: тест-кейсы ведутся в JIRA, там описаны шаги проверки работы с системой, а задачи на интеграционное тестирование слинкованы с jira epic, которые, в свою очередь, завязаны на бизнес-описание в Confluence.
3. Роль технического лидера достается периодически каждому члену команды. Большинство ребят получивших хоть сколько-нибудь крупный проект в свои руки склонны фиксировать в confluence, так как без этого дальнейшее согласование тех.решения и подготовка к нарезке на задачи просто не взлетит. Да и делать code review задач, скажем, по изменению конфигурации какой-нибудь стейт-машины при полном отсутствии диаграмм переходов статусов просто невыносимо.
С актуализацией дела обстоят хуже, но QA и аналитики, на мой взгляд, эту проблему решают.
Ну а мотивация писать об инцидентах описана в статье. Когда человек разбужен службой поддержки среди ночи, и понимает, что такой инцидент уже был, а никаких следов он не оставил и не может даже посмотреть, что было причиной в прошлый раз, то ему становится очень, очень обидно. Я сам не раз бывал в такой ситуации, от того и стартовал в свое время историю с ведением таблички вида «какой-мониторинг взорвался — линк на задачу в jira — причина возникновения — линк на репозиторий со скриптами для ремонта / запросы в базу для локализации». Когда такое часто повторяется появляется повод найти root cause и поставить задачу на ремонт.
Есть разные: у некоторых команд они проводятся на регулярной основе, и там идёт обсуждение актуальных проблем по технике, иногда пересмотр приоритетов задач в тех.бэклоге. Такие случаются раз в пару недель.
Есть кранчи ситуационные формата «другие команды набегают в нашу систему с пулл-реквестами, давайте-ка проведем централизованный ликбез по общему устройству и архитектуре».
Есть кейсы формата «я принес в админку проекта Vue, и надо бы поделиться с командой».
С одной стороны — да, на примере SRE всё описанное раскрывается ярче всего, а с другой стороны принципиальной разницы нет. Приведу пример: если вы занимаетесь разработкой игр, и у вас на запуске игры у персонажей не отрисовываются кожные покровы, и по итогу об этом судачит весь Интернет и всё завалено мемасами, то это вполне себе major incident и было бы бесконечно глупо повторить такую же ошибку при выпуске следующей игры на этом же движке. Так что практика разбора и формулирования action points тут уместны. Саппорт-инженеры, даже целые support-команды практикуются в самых разных it-related областях.
Ну и даже если вы поставляете оффлайновый софт для пары подрядчиков, и он время от времени ломается на рабочих станциях отдельных сотрудников, то всё равно придется эти баги сортировать по приоритетности, решать, кто какую возьмёт и так далее.
В руках команды зачастую не один проект. У меня вот есть монолит на Zend в котором используются элементы Symfony + MySql, а рядом есть первый результат распила этого монолита в виде микросервиса на Symfony + PostgreSql. Это уже, так или иначе, два фреймворка и две СУБД.
Четыре фреймворка, конечно же, всерьёз оцениваться не будут. Если, например, мы хотим симфониста, но у соискателя опыт только с Laravel, то не будем же мы отказываться. Мы спросим про ощущения от привычного фреймворка, о понимании паттернов проектирования лежащих в его основах.
Ну чинить приходится по очереди всем, в этом суть задумки, а техлид в команде тоже один, и он отвечает в полной мере за состояние и развитие всех подконтрольных команде систем. А «временные» техлиды тащат конкретные технические или бизнесовые проекты и принимают решение в их рамках. По мере роста и накопления опыта задачи становятся крупнее и сложнее, в некоторых командах техлид/тимлид в итоге перестают быть одним человеком и разделяются на архитектора и people-менеджера.
Если коротко, то перекосов стараемся избегать, у нас нет тех, кто всю дорогу тащит саппорт или только дизайнит новое.
в рамках этого процесса люди получают обратную связь о своей работе, могут быть уволены, премированы, повышены etc. Каждая встреча и комиссия на этот счёт уникальна, так как ачивки у всех каждый раз новые, а оценка производится с учётом актуального грейда. Что джуниору подвиг, то для senior утро понедельника.
Раньше делали вообще раз в квартал, но за такой краткий срок можно не успеть как следует проявить себя.
Не могу сказать, что процесс «вспомнить все достижение за полгода и рассказать почему я молодец» вызывает энтузиазм, тут есть свои шероховатости, но с тем, что вы описываете, к счастью, наш процесс ревью ничего общего не имеет.
Невыполнимые в полной мере цели вида «достичь таких-то показателей» — это в нашем случае обкатываемая сейчас модель OKR, и она на performance review не влияет. Она призвана направить множество людей / отделов / департаментов / всю компанию к общей цели, и тут ещё, пожалуй, предстоит проделать кучу работы.
Я верю в то, что человек может достигать хороших оценок даже не думая о всех этих 360 review, комиссиях, шкалах и «выполненных договорённостях», если у него есть цель и мотив для того чтобы не просто жать кнопки, но заботиться о результате своей работы. У кого-то есть врождённая усидчивость, внимательность, перфекционизм и прочие качества, что помогают с первого захода делать задачи самой разной сложности, попадать в эстимэйты, и это не остаётся незамеченным на ревью.
А у кого-то по-другому горят глаза, хочется всё починить, притащить в легаси систему удачный и подходящий паттерн проектирования, сделать более информативные мониторинги, забороть root cause типового саппорта, автоматизировать рутину, сделать бота оповещающего команду через телегу о зависших в code review реквестах. Такое проявление у нас действительно фигурирует в «фигне вроде ценностей компании» и мы зовём это ownership. Только мы не делаем из этого культ или мантру и не обмазываемся красивыми словами, а пробуем разные подходы для развития в людях таких качеств. Как раз дежурства и техлидство небольших проектов помогают лучше всего, так как «включается» ответственность за систему и появляется более глубокое понимание возможных последствий собственных решений. Полезна любая деятельность выходящая за рамки механического выполнения тикетов.
В данный момент большинство людей получающих эти условные четверки и пятёрки вспоминает о ревью один раз в середине полугодия, и второй раз когда нужно сесть и оформить «ачивки».
Вот я и говорю: критерии оценки нужно чётко формулировать, а не только цели. Если вы в итоге сделали восхитительную сложную и тяжёлую работу, «заперформили», получили премии, а с точки зрения бизнеса цель была одним большим провалом, то я по-прежнему не вижу от чего вложенные силы и труд могли бы не быть оценены и премированы по достоинству. Так что тут, на мой взгляд, смешивается как минимум две параллельно существующих проблемы.
Идеальной точно нет, но что мешает стремиться? Нужно четко формулировать критерии оценки. Например: «если ты делаешь только поставленные задачи и не проявляешь никакой инициативы, то скорее всего это тройка».
Ещё неплохим критерием является ценность проделанной работы для бизнеса. От этого критерия веет холодом, но бывают кейсы вида «разработчик принес по собственной инициативе code fixer, что ускорило процесс ревью и уменьшило время за которое фичи попадают в production». Никто не будет считать это в рублях, но профит очевиден, это будет отмечено и учтено в оценке.
Тройка порою даёт и другой эффект: «а как я могу получить оценку выше или промоушен». Это вопрос специфики человека и хорошая задача для руководителя. Ещё можно оперировать зарплатной вилкой в рамках грейда.
icinga — это из блока «так исторически сложилось», она появилась задолго до миграции в k8s и команда devops предпочла её как сравнительно простой инструмент для нотификаций.
Так что сервисы высыпают свои данные в prometheus либо он забирает их, а icinga уже наводит панику.
Про «long-term»: для этого используется ceph, проблем не испытываем уже очень давно.
По жизненному циклу метрик и корректировке вопрос отличный, но на моей памяти такого опыта не было: процесс создания новых метрик проходит такой же code review, как и любые другие изменения в коде, и если есть сомнения по наименованию, то они решаются до ввода в прод. Поэтому изменения почти всегда относятся к двум типам: правка трешхолдов в icinga (warning / alert / critical) и удаление метрики в случае если она утратила смысл.
То есть у ситуационных встреч обычно есть понятная тема, список вопросов и в итоге это доклад на 30-40 минут + 20 минут на вопросы и ответы.
У регулярных кранчей по сути формат обычной встречи в календаре: что влезло то и обсудили, но приветствуется наличие заранее составленного плана. Это же касается и прочих встреч вроде ретро и 1-на-1 лидов с разработчиками: если есть регулярная встреча и для неё нет понятного списка топиков, то она может пройти впустую.
1. Упоминание необходимости появления артефакта в Confluence прямо в definition of done задачи. Тут, кажется, понятно какие будут последствия.
2. Документация силами QA: тест-кейсы ведутся в JIRA, там описаны шаги проверки работы с системой, а задачи на интеграционное тестирование слинкованы с jira epic, которые, в свою очередь, завязаны на бизнес-описание в Confluence.
3. Роль технического лидера достается периодически каждому члену команды. Большинство ребят получивших хоть сколько-нибудь крупный проект в свои руки склонны фиксировать в confluence, так как без этого дальнейшее согласование тех.решения и подготовка к нарезке на задачи просто не взлетит. Да и делать code review задач, скажем, по изменению конфигурации какой-нибудь стейт-машины при полном отсутствии диаграмм переходов статусов просто невыносимо.
С актуализацией дела обстоят хуже, но QA и аналитики, на мой взгляд, эту проблему решают.
Ну а мотивация писать об инцидентах описана в статье. Когда человек разбужен службой поддержки среди ночи, и понимает, что такой инцидент уже был, а никаких следов он не оставил и не может даже посмотреть, что было причиной в прошлый раз, то ему становится очень, очень обидно. Я сам не раз бывал в такой ситуации, от того и стартовал в свое время историю с ведением таблички вида «какой-мониторинг взорвался — линк на задачу в jira — причина возникновения — линк на репозиторий со скриптами для ремонта / запросы в базу для локализации». Когда такое часто повторяется появляется повод найти root cause и поставить задачу на ремонт.
Есть кранчи ситуационные формата «другие команды набегают в нашу систему с пулл-реквестами, давайте-ка проведем централизованный ликбез по общему устройству и архитектуре».
Есть кейсы формата «я принес в админку проекта Vue, и надо бы поделиться с командой».
Ну и даже если вы поставляете оффлайновый софт для пары подрядчиков, и он время от времени ломается на рабочих станциях отдельных сотрудников, то всё равно придется эти баги сортировать по приоритетности, решать, кто какую возьмёт и так далее.
Четыре фреймворка, конечно же, всерьёз оцениваться не будут. Если, например, мы хотим симфониста, но у соискателя опыт только с Laravel, то не будем же мы отказываться. Мы спросим про ощущения от привычного фреймворка, о понимании паттернов проектирования лежащих в его основах.
Если коротко, то перекосов стараемся избегать, у нас нет тех, кто всю дорогу тащит саппорт или только дизайнит новое.
Раньше делали вообще раз в квартал, но за такой краткий срок можно не успеть как следует проявить себя.
Не могу сказать, что процесс «вспомнить все достижение за полгода и рассказать почему я молодец» вызывает энтузиазм, тут есть свои шероховатости, но с тем, что вы описываете, к счастью, наш процесс ревью ничего общего не имеет.
Я верю в то, что человек может достигать хороших оценок даже не думая о всех этих 360 review, комиссиях, шкалах и «выполненных договорённостях», если у него есть цель и мотив для того чтобы не просто жать кнопки, но заботиться о результате своей работы. У кого-то есть врождённая усидчивость, внимательность, перфекционизм и прочие качества, что помогают с первого захода делать задачи самой разной сложности, попадать в эстимэйты, и это не остаётся незамеченным на ревью.
А у кого-то по-другому горят глаза, хочется всё починить, притащить в легаси систему удачный и подходящий паттерн проектирования, сделать более информативные мониторинги, забороть root cause типового саппорта, автоматизировать рутину, сделать бота оповещающего команду через телегу о зависших в code review реквестах. Такое проявление у нас действительно фигурирует в «фигне вроде ценностей компании» и мы зовём это ownership. Только мы не делаем из этого культ или мантру и не обмазываемся красивыми словами, а пробуем разные подходы для развития в людях таких качеств. Как раз дежурства и техлидство небольших проектов помогают лучше всего, так как «включается» ответственность за систему и появляется более глубокое понимание возможных последствий собственных решений. Полезна любая деятельность выходящая за рамки механического выполнения тикетов.
В данный момент большинство людей получающих эти условные четверки и пятёрки вспоминает о ревью один раз в середине полугодия, и второй раз когда нужно сесть и оформить «ачивки».
Вот я и говорю: критерии оценки нужно чётко формулировать, а не только цели. Если вы в итоге сделали восхитительную сложную и тяжёлую работу, «заперформили», получили премии, а с точки зрения бизнеса цель была одним большим провалом, то я по-прежнему не вижу от чего вложенные силы и труд могли бы не быть оценены и премированы по достоинству. Так что тут, на мой взгляд, смешивается как минимум две параллельно существующих проблемы.
Ещё неплохим критерием является ценность проделанной работы для бизнеса. От этого критерия веет холодом, но бывают кейсы вида «разработчик принес по собственной инициативе code fixer, что ускорило процесс ревью и уменьшило время за которое фичи попадают в production». Никто не будет считать это в рублях, но профит очевиден, это будет отмечено и учтено в оценке.