Forwarded from anton egorushkov
f_12_09_Егорушков_Антон_BigTechNight_designed_final.pdf
4.6 MB
👍16🔥6
This media is not supported in the widget
VIEW IN TELEGRAM
🔥17❤🔥10😱5
https://events.yandex.ru/events/bigtechnight/records ищите тут материалы с BTN!
Forwarded from Инженер и Менеджер
Как_добиваться_успехов_на_переговорах.pdf
5.2 MB
У меня есть для вас подарок. Он поможет вам побеждать в переговорах.
Ведь когда устраиваешься на работу — переговоры о зарплате. Хочешь больше людей — переговоры о найме и ресурсах.
Крис Восс 27 лет проводил переговоры в ФБР, в том числе — с похитителями и настоящими террористами. Его методы спасали жизни. Теперь он учит этому бизнес.
Мой подарок — выжимка из его книги "Никаких компромиссов". В выжимке: система ведения переговоров, набор инструментов, конкретных приемов и критериев успеха. Если у вас есть время, купите и прочитайте книгу целиком. Если нет, мой гайд на 6 страниц поможет начать использовать методику. Без воды.
Бесплатно. Без email, регистрации и СМС. Просто заберите и используйте на следующей встрече.
Единственная просьба. Если гайд реально поможет — перешлите этот пост другу, коллеге или в чат. Ваши репосты это главный двигатель моего канала и главная моя мотивация продолжать.
Надеюсь, подарок вам понравится. Приятного чтения!
P.S. Если примените хотя бы одну технику на следующей неделе и она сработает — напишите в комментариях. Мне важна обратная связь.
Ведь когда устраиваешься на работу — переговоры о зарплате. Хочешь больше людей — переговоры о найме и ресурсах.
Крис Восс 27 лет проводил переговоры в ФБР, в том числе — с похитителями и настоящими террористами. Его методы спасали жизни. Теперь он учит этому бизнес.
Мой подарок — выжимка из его книги "Никаких компромиссов". В выжимке: система ведения переговоров, набор инструментов, конкретных приемов и критериев успеха. Если у вас есть время, купите и прочитайте книгу целиком. Если нет, мой гайд на 6 страниц поможет начать использовать методику. Без воды.
Бесплатно. Без email, регистрации и СМС. Просто заберите и используйте на следующей встрече.
Единственная просьба. Если гайд реально поможет — перешлите этот пост другу, коллеге или в чат. Ваши репосты это главный двигатель моего канала и главная моя мотивация продолжать.
Надеюсь, подарок вам понравится. Приятного чтения!
P.S. Если примените хотя бы одну технику на следующей неделе и она сработает — напишите в комментариях. Мне важна обратная связь.
Forwarded from The ExtremeCode Times
Кто нибудь расскажет мне как в бигтехах уживаются следующие взаимоисключающие параграфы?
1. Проблемы с софтом.
> Вечная бесконечная сборка-пересборка. Добрая половина времени разработки уходит на сборку.
> Отсутствие возможности запуска некоторых приложений вне прода во время разработки,
> Лапшекод в котором невозможно разобраться
> Проблемы с процессами, работяги гонят друг на друга и пытаются перекинуть свою работу на других
2. Все работяги как на подбор. Дохера вумные, за спиною книжки и небритые подмышки. Процесс найма, как будто там рокетсаенс на каждом шагу.
Почему сильные кадры делают слабо?
1. Проблемы с софтом.
> Вечная бесконечная сборка-пересборка. Добрая половина времени разработки уходит на сборку.
> Отсутствие возможности запуска некоторых приложений вне прода во время разработки,
> Лапшекод в котором невозможно разобраться
> Проблемы с процессами, работяги гонят друг на друга и пытаются перекинуть свою работу на других
2. Все работяги как на подбор. Дохера вумные, за спиною книжки и небритые подмышки. Процесс найма, как будто там рокетсаенс на каждом шагу.
Почему сильные кадры делают слабо?
ретро
важно: ретро это вам не спринт-ревью и звать туда абы кого не стоит. там должна быть только команда. только мы, кому есть что обсудить. над чем по рефлексировать.
на ретро можно хвастаться, ругаться, благодарить. но все должно быть подкреплено фактами.
рекомендую вообще использовать конструкцию с фактами. то есть: не «Вася опять сделал лажу», а «Василий не успел разобраться в задаче и сделал её неверно, задачу не приняли». или не «Вася красава!», но «Вася смог сделать 5 задач за спринт».
то есть, к этой самой конструкции можно применить действие. часто на ретро возникают обсуждения и задачи процессной части.
очевидно, что для «плохих» карточек действия обязательны, а для хороших? тоже! но можно их делать в формате: «чтобы все делали так же хорошо, нам нужно» или «улучшить постановку задач и перед взятием в работу проверять что все в команде понимают требования».
ретро может превращаться в нытинг. а фасилитатору нужно иметь силу воли и строгость модерации, чтобы все стало продуктивным.
задачи с ретро берутся в работу с высоким приоритетом.
важно: ретро это вам не спринт-ревью и звать туда абы кого не стоит. там должна быть только команда. только мы, кому есть что обсудить. над чем по рефлексировать.
на ретро можно хвастаться, ругаться, благодарить. но все должно быть подкреплено фактами.
рекомендую вообще использовать конструкцию с фактами. то есть: не «Вася опять сделал лажу», а «Василий не успел разобраться в задаче и сделал её неверно, задачу не приняли». или не «Вася красава!», но «Вася смог сделать 5 задач за спринт».
то есть, к этой самой конструкции можно применить действие. часто на ретро возникают обсуждения и задачи процессной части.
очевидно, что для «плохих» карточек действия обязательны, а для хороших? тоже! но можно их делать в формате: «чтобы все делали так же хорошо, нам нужно» или «улучшить постановку задач и перед взятием в работу проверять что все в команде понимают требования».
ретро может превращаться в нытинг. а фасилитатору нужно иметь силу воли и строгость модерации, чтобы все стало продуктивным.
задачи с ретро берутся в работу с высоким приоритетом.
не делай всё сам
для менеджера свойственно проводить все встречи самому. это зовется "лидировать".
но ведь нет, есть такое понятие "фасилитация". я долго держал его в негативной коннотации, но потом понял — помощь и сопровождение — вот что нужно вкладывать в фасилитацию.
а фасилитировать может кто угодно, не обязательно менеджер. а значит — вести встречи, следить за исполнением процесса и помогать — тоже!
это не освобождает менеджера от его обязанностей, но помогает каждому в команде быть частью процесса и ускорять, улучшать и пропускать это всё через себя.
и да, конечно, вся команда — это единое фасилитирующее. и менеджер или лид — лицо, принимающее решение и ответственность.
но если менеджер будет делать всё сам и завернет всё на себя — ему не стоит переходить дорогу не поглядев по сторонам.
для менеджера свойственно проводить все встречи самому. это зовется "лидировать".
но ведь нет, есть такое понятие "фасилитация". я долго держал его в негативной коннотации, но потом понял — помощь и сопровождение — вот что нужно вкладывать в фасилитацию.
а фасилитировать может кто угодно, не обязательно менеджер. а значит — вести встречи, следить за исполнением процесса и помогать — тоже!
это не освобождает менеджера от его обязанностей, но помогает каждому в команде быть частью процесса и ускорять, улучшать и пропускать это всё через себя.
и да, конечно, вся команда — это единое фасилитирующее. и менеджер или лид — лицо, принимающее решение и ответственность.
но если менеджер будет делать всё сам и завернет всё на себя — ему не стоит переходить дорогу не поглядев по сторонам.
😁4
Forwarded from Enabling.team Insights
InfoQ Trends DevOps and Cloud 2025
В октябре 2025 года сообщество InfoQ выпустило отчёт DevOps and Cloud Trends, в котором представлены ключевые тенденции в области DevOps и облачных технологий.
Из интересных технологий отметим: Platform engineering teams, DevEx Frameworks, MCP-based ops tooling, AI agents in cloud engineering, Industry-aggregated incident analysis, Team Topologies, Measuring performance, DORA metrics и др.
Подробнее про ключевые тренды из отчета читайте в нашем обзоре.
В октябре 2025 года сообщество InfoQ выпустило отчёт DevOps and Cloud Trends, в котором представлены ключевые тенденции в области DevOps и облачных технологий.
Из интересных технологий отметим: Platform engineering teams, DevEx Frameworks, MCP-based ops tooling, AI agents in cloud engineering, Industry-aggregated incident analysis, Team Topologies, Measuring performance, DORA metrics и др.
Подробнее про ключевые тренды из отчета читайте в нашем обзоре.
Forwarded from Кулешов разгоняет IT | AI
Инфекция CTO. Или парадокс накрутчиков в российском IT менеджменте.
Заметили, как каждый второй в IT за последние пару лет начал описывать свою должность как C-level?
И всё бы ничего — можно было бы просто посмеяться со стороны, если бы это не стало напоминать тот самый фильтр «опыта от трёх лет», который железобетонно перекрыл дорогу новичкам в российское IT.
Теперь, чтобы манагеру просто попасть на некоторые мероприятия или выступить там, нужно стать волком и прикрутить к себе громкий титул, желательно с буквой C. Причём никого не волнует, ты CTO Google Cloud или CTO стартапа из трёх человек, основанного твоим другом вчера. И все это делают.
Но это ещё цветочки. С поиском работы началось то же самое. Ни результативность, ни достижения, ни проекты, ни твои навыки никого не интересуют. Отфильтруют тебя только по двум вещам: сколько у тебя штатных единиц в подчинении и насколько громко сияет буква «С» в твоём титуле. Причем, это одновременно стреляет и по компаниям, которые теперь вынуждены плодить псевдо-С-level вакансии, чтобы люди соглашались у них работать.
А дальше — пока слабохарактерные кодеры, не умеющие врать, честно проходят миллионы алгоритмических интервью и системных дизайнов, чтобы работать за копейки, просто нужно успешно сказать про «700 тысяч человек в подчинении», добавить, какой ты великий CTO/CDO/CIO/CPO, и получить работу очередного «CTO» в следующей компании.
При этом в реальности, когда мы говорим о Top Management Team (TMT) или Senior Leaders — то это группа руководителей, влияющих на организацию целиком. Сюда входят CEO, CFO, CTO, CIO, CMO и другие «chief»-роли. Это те, кто определяют стратегию и направление развития компании в целом.
Так что если ты — тимлид команды из трёх человек и не отчитываешься генеральному директору или совету директоров, то пожалуйста, прекрати позориться, выдумывать себе C-level титулы и притворяться большим боссом.
Нет, ты не C-level. Эти роли в компании — единичный товар. Не бывает так, чтобы у тебя в конторе была сотня таких же бедолаг на букву «С».
Открой трудовую, посмотри, что там написано. Вразумительно и с чувством прочти это вслух, можешь даже не читать название своей компании, чтобы не разрушить картинку Волка с Уолл-стрит у себя в голове. А потом, напиши это у себя в подписи под именем. Спасибо.
PS возможно, таким честным постом обижу многих своих товарищей и знакомых. Но этим лишь докажу свою правоту. Поэтому воспринимайте это как мягкий укол, чтобы сделать нашу общую с вами индустрию лучше. Обнимаю! Всегда ваш, "завистливый не-CTO-но-мог-бы-быть" Кулешов.
Заметили, как каждый второй в IT за последние пару лет начал описывать свою должность как C-level?
И всё бы ничего — можно было бы просто посмеяться со стороны, если бы это не стало напоминать тот самый фильтр «опыта от трёх лет», который железобетонно перекрыл дорогу новичкам в российское IT.
Теперь, чтобы манагеру просто попасть на некоторые мероприятия или выступить там, нужно стать волком и прикрутить к себе громкий титул, желательно с буквой C. Причём никого не волнует, ты CTO Google Cloud или CTO стартапа из трёх человек, основанного твоим другом вчера. И все это делают.
Но это ещё цветочки. С поиском работы началось то же самое. Ни результативность, ни достижения, ни проекты, ни твои навыки никого не интересуют. Отфильтруют тебя только по двум вещам: сколько у тебя штатных единиц в подчинении и насколько громко сияет буква «С» в твоём титуле. Причем, это одновременно стреляет и по компаниям, которые теперь вынуждены плодить псевдо-С-level вакансии, чтобы люди соглашались у них работать.
А дальше — пока слабохарактерные кодеры, не умеющие врать, честно проходят миллионы алгоритмических интервью и системных дизайнов, чтобы работать за копейки, просто нужно успешно сказать про «700 тысяч человек в подчинении», добавить, какой ты великий CTO/CDO/CIO/CPO, и получить работу очередного «CTO» в следующей компании.
При этом в реальности, когда мы говорим о Top Management Team (TMT) или Senior Leaders — то это группа руководителей, влияющих на организацию целиком. Сюда входят CEO, CFO, CTO, CIO, CMO и другие «chief»-роли. Это те, кто определяют стратегию и направление развития компании в целом.
Так что если ты — тимлид команды из трёх человек и не отчитываешься генеральному директору или совету директоров, то пожалуйста, прекрати позориться, выдумывать себе C-level титулы и притворяться большим боссом.
Нет, ты не C-level. Эти роли в компании — единичный товар. Не бывает так, чтобы у тебя в конторе была сотня таких же бедолаг на букву «С».
Открой трудовую, посмотри, что там написано. Вразумительно и с чувством прочти это вслух, можешь даже не читать название своей компании, чтобы не разрушить картинку Волка с Уолл-стрит у себя в голове. А потом, напиши это у себя в подписи под именем. Спасибо.
PS возможно, таким честным постом обижу многих своих товарищей и знакомых. Но этим лишь докажу свою правоту. Поэтому воспринимайте это как мягкий укол, чтобы сделать нашу общую с вами индустрию лучше. Обнимаю! Всегда ваш, "завистливый не-CTO-но-мог-бы-быть" Кулешов.
👍11❤5💯5👏2
ограничения
https://theengineeringmanager.substack.com/p/the-beauty-of-constraints
нам нужны ограничения. нужно понимать, когда сказать "нет" или отсечь часть ненужного.
нет, это не про приоритизацию, но идет рядом с ней.
RICE/ICE это сортировка (охват, влияние, уверенность в оценке и трудозатраты), а вот отсечение нужно делать через ограничения: скоупа, ресурсов, времени. ведь всегда именно их и не хватает!
например: режем скоуп до конкретно того, что нужно для работы, без рюшечек и свистоперделок. четко определяем критерий успеха, определяем то, что будет по-умолчанию четко и ясно. не раздуваем команду и инфраструктуру под проект (даже если можем). ставим дедлайны, для которых придется постараться (но не овертаймить) и постоянно демонстрируешь результат в рамках интервалов (спринтов или других удобных обеим сторонам отрезков).
как это делать на практике:
- спросить "эти требования можно усечь?" и "кто задал эти требования?"
- исключить все шаги, которые не приводят к поломке результата. если сломалось — вернись
- тюнь (подкручивай) только то, что реально нужно, то что у тебя останется. а не всё, что видишь по пути
- сокращай (уменьшай) цикл обучения: попробовали, измерили, осознали, поправили, снова пробуем
- автоматизируй уже когда понял что всё оставшееся нужно автоматизировать (чтобы не тратить силы на ненужное)
- задай вопрос "что я могу сделать, чтобы уложиться в половину времени/ресурсов на проект?"
ну и, разумеется, постоянно спрашивай "можно ли это сделать проще/дешевле/быстрее/меньшим ресурсом?"
да, это не универсальное решение и его не нужно применять всегда, но оно очень отрезвляет и помогает вернуться в реальность.
не заливай ресурсами, деньгами и инфраструктурой то, что можно сделать хорошо и без этого.
https://theengineeringmanager.substack.com/p/the-beauty-of-constraints
нам нужны ограничения. нужно понимать, когда сказать "нет" или отсечь часть ненужного.
нет, это не про приоритизацию, но идет рядом с ней.
RICE/ICE это сортировка (охват, влияние, уверенность в оценке и трудозатраты), а вот отсечение нужно делать через ограничения: скоупа, ресурсов, времени. ведь всегда именно их и не хватает!
например: режем скоуп до конкретно того, что нужно для работы, без рюшечек и свистоперделок. четко определяем критерий успеха, определяем то, что будет по-умолчанию четко и ясно. не раздуваем команду и инфраструктуру под проект (даже если можем). ставим дедлайны, для которых придется постараться (но не овертаймить) и постоянно демонстрируешь результат в рамках интервалов (спринтов или других удобных обеим сторонам отрезков).
как это делать на практике:
- спросить "эти требования можно усечь?" и "кто задал эти требования?"
- исключить все шаги, которые не приводят к поломке результата. если сломалось — вернись
- тюнь (подкручивай) только то, что реально нужно, то что у тебя останется. а не всё, что видишь по пути
- сокращай (уменьшай) цикл обучения: попробовали, измерили, осознали, поправили, снова пробуем
- автоматизируй уже когда понял что всё оставшееся нужно автоматизировать (чтобы не тратить силы на ненужное)
- задай вопрос "что я могу сделать, чтобы уложиться в половину времени/ресурсов на проект?"
ну и, разумеется, постоянно спрашивай "можно ли это сделать проще/дешевле/быстрее/меньшим ресурсом?"
да, это не универсальное решение и его не нужно применять всегда, но оно очень отрезвляет и помогает вернуться в реальность.
не заливай ресурсами, деньгами и инфраструктурой то, что можно сделать хорошо и без этого.
Substack
The beauty of constraints
Having less choice often creates more opportunity.
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Почему ретроспективы не работают
Многие ретроспективы дисфункциональны. Вместо того, чтобы служить механизмом continuous improvement, они помогают команде отпустить чувство вины по поводу проблем, которые не чинятся. Так получается, потому что стандартный исход ретроспективы – записать все проблемы в трекер, и либо вообще больше к ним не возвращаться, либо немного поисследовать, и только потом забить.
При этом, если покопать в Toyota Production System, откуда вообще пошла идея continuous improvement, можно найти конкретные вещи, которых не хватает сломанным ретроспективам:
👉В TPS у всех участников производственного процесса есть возможность (и более того, требование) остановить процесс разработки, когда обнаруживается проблема – вместо того, чтобы вернуться к ней только через пару недель на запланированной ретроспективе.
👉В TPS проблему пытаются исправить сразу же, не откладывая. В наших реальностях мы пытаемся быстро ее запатчить, обещая, что в будущем обязательно вернемся и поправим как надо – но приоритеты до этого никогда не доходят.
👉В TPS у результатов root cause analysis есть четкие дедлайны, ответственные и понятный ожидаемый исход. Сравните со стандартными "улучшить процесс" или "обновить документацию", которые появляются после ретроспектив.
👉В TPS действия, которые предпринимают по итогам инцидента, должны не давать повторяться исходной проблеме. Иначе говоря, это постоянные решения, а не временные.
Многие ретроспективы дисфункциональны. Вместо того, чтобы служить механизмом continuous improvement, они помогают команде отпустить чувство вины по поводу проблем, которые не чинятся. Так получается, потому что стандартный исход ретроспективы – записать все проблемы в трекер, и либо вообще больше к ним не возвращаться, либо немного поисследовать, и только потом забить.
При этом, если покопать в Toyota Production System, откуда вообще пошла идея continuous improvement, можно найти конкретные вещи, которых не хватает сломанным ретроспективам:
👉В TPS у всех участников производственного процесса есть возможность (и более того, требование) остановить процесс разработки, когда обнаруживается проблема – вместо того, чтобы вернуться к ней только через пару недель на запланированной ретроспективе.
👉В TPS проблему пытаются исправить сразу же, не откладывая. В наших реальностях мы пытаемся быстро ее запатчить, обещая, что в будущем обязательно вернемся и поправим как надо – но приоритеты до этого никогда не доходят.
👉В TPS у результатов root cause analysis есть четкие дедлайны, ответственные и понятный ожидаемый исход. Сравните со стандартными "улучшить процесс" или "обновить документацию", которые появляются после ретроспектив.
👉В TPS действия, которые предпринимают по итогам инцидента, должны не давать повторяться исходной проблеме. Иначе говоря, это постоянные решения, а не временные.
Lucas F. Costa
Why your retrospectives don't work and how to fix them
Hot takes and cold truths on software, startups, and the lies we tell ourselves.
❤4
люди
где бы я ни работал, чем бы ни занимался, даже когда был сисадмином и думал что серверная мой дом и патч-панели — мои друзья — я общался с людьми. я знакомился, помогал, решал их проблемы и задачи.
эти люди менялись, менялся и я, менялись работы и шло время.
людей становилось все больше, но всегда оставались определенные люди, с которыми в любой момент можно снова поработать, встретиться, помочь им или которые помогут тебе.
это не какой-то круг, не какие-то рукопожатия. это люди.
оборачивать это все в нетворкинг, и тем более, учиться этому на курсах — это какой-то другой мир.
даже не потому что времени жалко, а потому что такие контакты будут просто ещё одной визиткой в пачке других.
душа? может и душа.
вот сегодня встретился с Севой. работали с ним уже 4 года назад, а людьми остались до сих пор.
где бы я ни работал, чем бы ни занимался, даже когда был сисадмином и думал что серверная мой дом и патч-панели — мои друзья — я общался с людьми. я знакомился, помогал, решал их проблемы и задачи.
эти люди менялись, менялся и я, менялись работы и шло время.
людей становилось все больше, но всегда оставались определенные люди, с которыми в любой момент можно снова поработать, встретиться, помочь им или которые помогут тебе.
это не какой-то круг, не какие-то рукопожатия. это люди.
оборачивать это все в нетворкинг, и тем более, учиться этому на курсах — это какой-то другой мир.
даже не потому что времени жалко, а потому что такие контакты будут просто ещё одной визиткой в пачке других.
душа? может и душа.
вот сегодня встретился с Севой. работали с ним уже 4 года назад, а людьми остались до сих пор.
❤25👍14💯8
притащили чудесное (конечно, я же там участвовал)
хочу прокомментировать то, что увидел и что происходит в головах общества.
однако, сразу осекусь: я и с devops раньше борцунствовал, но если всем ок сисадминам платить большие зарплаты, не получая практик — то кто я такой, чтобы с этим бороться?(я сыч, я всю спикерскую деятельность на это положил и буду продолжать)
Кто отвечает за надёжность?
тут я хочу ответить просто и коротко: YBIYRI. а в ответах даже нет "разработчик сервиса"))) это как?)
то что SRE это молодая роль — в первую очередь заслуга размытия понимания роли как таковой. devops и SRE это вообще синонимы. в проде что-то полетело — зовите опсов (а это кто? SRE или devops? а может вообще sysops?), а если у вас облачная инфраструктура и managed сервисы? кого звать?
и как следствие — компаниям нужен универсал, понимающий код и подтиряющий сопельки + тот, кто напишет пайп и закрутит все гайки безопасности. да, это SRE)
про вкатунов и "я за три года до сеньора" — не буду.
девятки после запятой и девятки до запятой — это задача не SRE, а CTO.
дальше в отчете идет статистика по количеству SRE на компанию. и тут я не могу не вспомнить вопрос с собеседований "сколько должно быть инженеров на разработчика?" или правильнее сказать "сколько разработчиков у одного инженера?".
мое правило: коэффициент 0,1 — 10% должен быть инженерный состав, всё что ниже — будет отзываться так или иначе. хотя, правильнее было бы построить кривую зависимости. ну и отдать должное разным организационным подходам и практикам. чем лучше — тем проще и спокойнее инженеру и коэффициент можно уменьшить)
самое забавное что я слышал про SRE — что это девопс с дежуркой) но дежурка есть у всех и отчет это подтверждает. помимо дежурки, конечно, есть и инцидент и проблем-менеджмент (о них мы еще точно поговорим и не раз). но в отчете мне бросилось в глаза что упор на автоматизацию рутины делают... сисдамины! да-да! тогда как платформенных инженеров заставляют участвовать в он-коллах) что происходит с рынком?
пункты про сложность отстаивания своего мнения я спишу на плохие процессы, которые не позволяют каждому открыто и прозрачно влиять на инженерные и архитектурные решения (опять же, процессная проблема)
разумеется, более половины (хаха, статистика, 51%) не разделяют SRE и devops. да и зачем? ведь это всё просто фильтр, на деле люди одинаковые и работают одинаково? о, нет) о, нет! это не так. и ведь дальше раскрывается почему:
- операционка
- разрыв контекста
- нет денег на разделение
догадаетесь, что тут будет ключом к успеху?
и что меня расстроило больше всего в этом отчете — так это то6 что лишь в 2,5% случаев за инциденты и дежурства по сервису отвечает сама разработка (первичное реагирование). и, как следствие — лишь у полвины описаны инструкции и ранбуки по инцидентам.
но ладно, радует что об этом говорят и смотрят на ситуацию с разных сторон.
что ж, добро пожаловать в эру, когда мы (я) будем рассказывать и про CRE. пристегивайтесь, будет душно.
хочу прокомментировать то, что увидел и что происходит в головах общества.
однако, сразу осекусь: я и с devops раньше борцунствовал, но если всем ок сисадминам платить большие зарплаты, не получая практик — то кто я такой, чтобы с этим бороться?
Кто отвечает за надёжность?
тут я хочу ответить просто и коротко: YBIYRI. а в ответах даже нет "разработчик сервиса"))) это как?)
то что SRE это молодая роль — в первую очередь заслуга размытия понимания роли как таковой. devops и SRE это вообще синонимы. в проде что-то полетело — зовите опсов (а это кто? SRE или devops? а может вообще sysops?), а если у вас облачная инфраструктура и managed сервисы? кого звать?
и как следствие — компаниям нужен универсал, понимающий код и подтиряющий сопельки + тот, кто напишет пайп и закрутит все гайки безопасности. да, это SRE)
про вкатунов и "я за три года до сеньора" — не буду.
девятки после запятой и девятки до запятой — это задача не SRE, а CTO.
дальше в отчете идет статистика по количеству SRE на компанию. и тут я не могу не вспомнить вопрос с собеседований "сколько должно быть инженеров на разработчика?" или правильнее сказать "сколько разработчиков у одного инженера?".
мое правило: коэффициент 0,1 — 10% должен быть инженерный состав, всё что ниже — будет отзываться так или иначе. хотя, правильнее было бы построить кривую зависимости. ну и отдать должное разным организационным подходам и практикам. чем лучше — тем проще и спокойнее инженеру и коэффициент можно уменьшить)
самое забавное что я слышал про SRE — что это девопс с дежуркой) но дежурка есть у всех и отчет это подтверждает. помимо дежурки, конечно, есть и инцидент и проблем-менеджмент (о них мы еще точно поговорим и не раз). но в отчете мне бросилось в глаза что упор на автоматизацию рутины делают... сисдамины! да-да! тогда как платформенных инженеров заставляют участвовать в он-коллах) что происходит с рынком?
пункты про сложность отстаивания своего мнения я спишу на плохие процессы, которые не позволяют каждому открыто и прозрачно влиять на инженерные и архитектурные решения (опять же, процессная проблема)
разумеется, более половины (хаха, статистика, 51%) не разделяют SRE и devops. да и зачем? ведь это всё просто фильтр, на деле люди одинаковые и работают одинаково? о, нет) о, нет! это не так. и ведь дальше раскрывается почему:
- операционка
- разрыв контекста
- нет денег на разделение
догадаетесь, что тут будет ключом к успеху?
и что меня расстроило больше всего в этом отчете — так это то6 что лишь в 2,5% случаев за инциденты и дежурства по сервису отвечает сама разработка (первичное реагирование). и, как следствие — лишь у полвины описаны инструкции и ранбуки по инцидентам.
но ладно, радует что об этом говорят и смотрят на ситуацию с разных сторон.
что ж, добро пожаловать в эру, когда мы (я) будем рассказывать и про CRE. пристегивайтесь, будет душно.
Егор опубликовал пост про рычаги управления, а я решил чуточку разобрать.
числа. многие считают что через числа круто можно менять все параметры систем, процессов и прочее. но нет, числа можно измерять, достаточно понятно, их удобно обсуждать. но системно влиять цифры и числа на что-то — не будут.
запасы и буферы. если запасов мало — мы будем на острие, но постоянно бояться мелких колебаний. а если запасы большие — то просто будем очень инертными и начнем стагнировать.
материальные потоки. например, нахождение бутылочных горлышек или недостаточно утилизированных мест. управление потоками позволит существенно, но долго и дорого, менять что-то в системе.
задержки. мы что-то сделали и ждем. мы что-то получили и забыли уже почему. например — обратная связь. или строительство системы. физические процессы изменять мы не можем, но влиять на адаптацию системы — должны.
сила отрицательной обратной связи. то есть то, что возвращает систему в стабильное состояние. чем их больше, тем устойчивее система.
сила положительной обратной связи. те связи, что усиливаются сами по себе. они могут расшатать систему или вызвать её рост.
информационные потоки. ведь информация — то, откуда система черпает свое состояние. чем прозрачнее — тем быстрее и лучше исправляются проблемы.
правила системы. законы, стандарты, разрешения. понятный рычаг, к тому же действует на долгую перспективу.
способность к самоорганизации. возможность создавать новые правила и связи без внешних вмешательств.
цели систем. куда стремится система. надо очевидно обозначить что цели могут разниться. рост против стабильности. фичи против качества. если мы меняем цель системы — мы меняем всё поведение системы.
парадигма системы. набор предположений и ценностей (из них надо выращивать цели, правила и структуры системы). парадигмы очень сильно меняют систему, но они и очень устойчивые.
сила выхода за рамки парадигм. если участники системы могут выйти за рамки текущей парадигмы и сменить способ мышления — изменения не заставят себя долго ждать. нужно уметь видеть системы в целом, без текущих концепций.
поэтому, если вы видите, что что-то пора менять или придя на новое место свежим взглядом видите пробелмы — надо выбрать через какие рычаги вы будете менять поведение системы. чтобы не потратить силы на легкие рычаги, а система вернется в прошлое состояние.
числа. многие считают что через числа круто можно менять все параметры систем, процессов и прочее. но нет, числа можно измерять, достаточно понятно, их удобно обсуждать. но системно влиять цифры и числа на что-то — не будут.
запасы и буферы. если запасов мало — мы будем на острие, но постоянно бояться мелких колебаний. а если запасы большие — то просто будем очень инертными и начнем стагнировать.
материальные потоки. например, нахождение бутылочных горлышек или недостаточно утилизированных мест. управление потоками позволит существенно, но долго и дорого, менять что-то в системе.
задержки. мы что-то сделали и ждем. мы что-то получили и забыли уже почему. например — обратная связь. или строительство системы. физические процессы изменять мы не можем, но влиять на адаптацию системы — должны.
сила отрицательной обратной связи. то есть то, что возвращает систему в стабильное состояние. чем их больше, тем устойчивее система.
сила положительной обратной связи. те связи, что усиливаются сами по себе. они могут расшатать систему или вызвать её рост.
информационные потоки. ведь информация — то, откуда система черпает свое состояние. чем прозрачнее — тем быстрее и лучше исправляются проблемы.
правила системы. законы, стандарты, разрешения. понятный рычаг, к тому же действует на долгую перспективу.
способность к самоорганизации. возможность создавать новые правила и связи без внешних вмешательств.
цели систем. куда стремится система. надо очевидно обозначить что цели могут разниться. рост против стабильности. фичи против качества. если мы меняем цель системы — мы меняем всё поведение системы.
парадигма системы. набор предположений и ценностей (из них надо выращивать цели, правила и структуры системы). парадигмы очень сильно меняют систему, но они и очень устойчивые.
сила выхода за рамки парадигм. если участники системы могут выйти за рамки текущей парадигмы и сменить способ мышления — изменения не заставят себя долго ждать. нужно уметь видеть системы в целом, без текущих концепций.
поэтому, если вы видите, что что-то пора менять или придя на новое место свежим взглядом видите пробелмы — надо выбрать через какие рычаги вы будете менять поведение системы. чтобы не потратить силы на легкие рычаги, а система вернется в прошлое состояние.
Telegram
Teamlead Good Reads – ежедневные советы про менеджмент людей и команд
Как менять поведение систем
Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно…
Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно…
а вот у нас на прошлом месте
в одной там компании, которую я не буду называть, делали вот так!
а еще знаете, во всех бигтехах принято делать вот такие вещи.
знаете, по моему опыту — лучше делать следующим образом.
но если что — в ИМЯРЕК обычно ПРОЦЕСС иначе проходит.
так вот: если у вас есть опыт, которым вы хотите поделиться — хорошенько покрутите текущую ситуацию и примерьте пример до конца. не нужно вслепую доводить до "скопируем", но берите лучшее из своего (и чужого) опыта, давая простор для эволюционных изменений и роста.
либо вовсе, забудьте всё, что учили в школе, оно вам не понадобится, начинайте заново, с чистого листа и делайте хорошо.
и нет, я вроде не про то, что я на новом месте)))
в одной там компании, которую я не буду называть, делали вот так!
а еще знаете, во всех бигтехах принято делать вот такие вещи.
знаете, по моему опыту — лучше делать следующим образом.
но если что — в ИМЯРЕК обычно ПРОЦЕСС иначе проходит.
так вот: если у вас есть опыт, которым вы хотите поделиться — хорошенько покрутите текущую ситуацию и примерьте пример до конца. не нужно вслепую доводить до "скопируем", но берите лучшее из своего (и чужого) опыта, давая простор для эволюционных изменений и роста.
либо вовсе, забудьте всё, что учили в школе, оно вам не понадобится, начинайте заново, с чистого листа и делайте хорошо.
и нет, я вроде не про то, что я на новом месте)))
😁12
наконец-то запустили лендинг)
https://observability-conf.ru я там в ПК, но еще и выступлю со стендапом(даешь антикризисную коммуникацию)
последние несколько лет плотно дружу с ребятами из команды наблюдаемости (не важно где они, в какой компании), поэтому решил что мое участие в этой конфе обязательное.
да, на техно-трек еще нужны спикеры, но мест там не много, уже затащили кучу спикеров. поехали!
https://observability-conf.ru я там в ПК, но еще и выступлю со стендапом
последние несколько лет плотно дружу с ребятами из команды наблюдаемости (не важно где они, в какой компании), поэтому решил что мое участие в этой конфе обязательное.
да, на техно-трек еще нужны спикеры, но мест там не много, уже затащили кучу спикеров. поехали!
❤11🔥5