Спасибо ИТМО, лично Тане за возможность выступить перед такой активной и интересующейся аудиторией.
было чуть суматошно и капельку кустарно, но зато душевно.
спасибо новым подписчикам, надеюсь, вам тут понравится.
доклад мне понравился, я рассказал что хотел и по отзыву аудитории — вы получили что хотели. если что не поняли — читайте презентацию, смотрите запись или просто задавайте вопросы.
на Мерж будет чуточку иначе, но для закрепления информации — полезно послушать.
Дима вот два раза послушает))

в своей работе мы расследуем инциденты с помощью RCA — root cause analysis — поиска коренной причины.
конечно, не обязательно его применять только для инцидентов и проблем, можно пользоваться для определения текущего или целевого поведения сервиса и его архитектуры.

коренная (или причинная) проблема может быть связана с человеческим фактором, ошибкой, сбоем, проблемой процесса, да и вообще практически любой причиной.

при использовании подхода RCA надо:
- определить что происходит, не ограничиваясь симптомами, лучше построить причинную связь и последовательность
- понять что требуется для устранения инцидента с учетом коренной проблемы
- предотвращать повторное возникновение такой же ситуации вновь

самым удобным подходом для определения коренной причины считается "5 почему". когда на каждый возникший вопрос ответ будет "почему?". копаем, пока не поймем первопричину.

так же, можно пользоваться причинно-следственной диаграммой Исикавы, в которой от основной проблемы мы строим ответвления причин и следствий

плюс, перечислю несколько других способов (баззворды для гугла): FMEA, FTA, диаграмма Парето, диаграмма рассеяния

но во всех этих методах есть важное "но" — это радость от найденной "той самой" и единственной коренной причины. а еще за решение этой причины будет один ответственный.
кроме этого, фокус окружающих обстоятельств и элементов теряется из виду. это так не работает для сложных систем (которые у нас с вами в работе и есть).

да, если мы нашли что проблема была в человеческом факторе, мы говорим "я так больше не буду, понял-принял" и на этом завершаем расследование. а нужно стартовать с этой точки — например, вводя культуры и практики, которые покрывают подобные случаи. да и не слишком это blameless назначать ответственного за инцидент и проблему, не находите?

в общем, невозможно контролировать все внешние и внутренние факторы, а значит и невозможно найти ту самую, единственную и неповторимую коренную причину и ответственного за неё. это не значит, что не надо искать. просто стоит пересмотреть свои процессы. а устранять нужно все найденные коренные причины, проверяя текущее поведение системы после каждого исправления. скорее всего, метод и выбранное решение причины повлияет на то, что будет являться коренной причиной.

вау, многабукаф

комьюнити, давайте помогать! у кого есть вакансии стажеров или джунов инженеров devops?

на конференции в ИТМО ко мне подошел парень и попросил помощи.

мы причесали резюме и я разослал его любимым рекрутерам. пока пусто, поэтому прошу вашей помощи.
по запросу, в ЛС скину резюме.

с меня крыса 🐀

ага, значит так:

я написал принципы капибары. они шуточные, но вполне могут быть использованы как ориентир в работе и поведении. вполне допускаю, что они однобоки и не подойдут вам, тебе или даже мне. в таком случае — надо описать свои принципы. может, кодекс акулы? акуле ведь плевать?

то что у меня получилось, очень близко по духу к devops методологии, поэтому пощу их сюда.

Капибара – самый большой грызун.
А мы — знаем очень многое в нашей компании. Мы хотим всех научить тому, что умеем сами. Мы не хищники и не ищем жертв. Но если кто-то стал бревном – мы его покусаем!

Капибара – добрая
Мы должны быть и будем прежде всего добрыми к своим коллегам и самим себе. Мы хотим понять проблему и решить ее.

Клан
У капибары есть клан, а у нас – есть кора. Мы вместе, а значит – друг за друга горой. Мы всегда придем на помощь друг другу и подскажем ответ даже на самый глупый вопрос. Глуп тот, кто не задал вопроса.
Каждый капи готов помочь соседнему клану как своему.

Плодовитость и готовность жить
Капибары обычно держат по 5-8 малышей в клане. При этом, каждый новый малыш в минимальные сроки может встать на ноги и сделать первые шаги. Значит, мы учим новичков максимально эффективно и главная цель – сделать их самостоятельными.

Дрессировка и обучение
В домашних условиях, капибары очень хорошо обучаются. Мы учим и обучаемся сами, непрерывно и с удовольствием. Если хочешь что-то изучить – просто попроси. А если хочешь обучить – сделай это немедленно. Обо всех новых знаниях рассказывай всем вокруг!

Домик для других
Капибары не против, чтобы птички и мелкие грызуны оставались для передышки на их теле. А это значит, что мы гостеприимны и всегда готовы помочь, приютить, рассказать как что делать любому входящему в нашу зону. 

Прячемся от хищников
Не смотря на свою медлительность, капи очень хорошо прячутся, потому что отлично изучили территрию и пользуются всеми преимуществами среды. Значит, что мы хорошо знаем окружающие нас вещи, архитектуры и хорошо в них разбираемся. 
Если у капи отнимают еду – капи не расстроится. У нее всегда есть запас, а еще она хорошо умеет спрятать еду от хищников и воришек. Да и вообще капибара не расстроится: она дружелюбна и поделилась едой.

Любим водные процедуры и чистоту.
Капи не гадят где живут, работают и кушают, часто принимают водные процедуры. А мы не портим жизнь себе и окружающим, убираем все хвосты в бэклог, наводя чистоту и вычищаем техдолг. Кроме того, мы не любим жару и спешку. Поэтому, собираем мысли в кучку и делаем всё с холодной головой. А еще мы не устраивем пожаров самостоятельно и знаем как потушить возникшие.

Дружелюбные болтушки
Капибары очень дружелюбны и болтливы. Это не значит, что слова должны быть пустыми и лишь бы занять время. Но мы всегда должны быть готовы развернуто ответить и хорошо описать необходимую информацию.

Любим покушать
Капибары прожорливы и кушают по 3-4 кг сена в день. А мы берем много задач, но не допускаем состояния "мне плохо от еды". При этом, мы разборчивы и абы что в работу не берем – просим правильно оформлять задачи, писать критерии приемки и сами оцениваем задачи перед работой. Мы не хотим быть толстыми, а значит – не хотим перегрузиться задачами. Оцениваем свою производительность объективно.

Любознательность
Капибара – любопытная, постоянно учится и движется. Если на одной и той же территории ей стало скучно – она найдет новый ландшафт для жизни и творчества, освоит его и улучшит. Да и новые друзья – это круто!

про карго-культ

ко мне вчера подошли и спросили "что делать, если у нас карго-культ?"
мой ответ был прост "не делать так, а сделать как нужно вам".

проблема была в том, что в компании сверху навязаны определенные карго-практики (потому что никто в руководстве, видимо, не понял что это и зачем, но знает что такие же вещи работают у других компаний). исполнители сказали "так точно" и пошли делать так, как им сказали: рисовать цифры, приводить цифры к желаемому результату и не понимать что это всё должно значить.

как итог: люди делают работу ради работы, подстраивают циферки, показывают их начальству, оно смотрит, кивает, не понимает и требует продолжения банкета. очевидно, банкет за деньги руководства.

в такую компанию зовут активатора изменений (человека, который зафасилитирует и поможет сделать правильно), но за что браться — ему не понятно.

я предлагаю экспансивный путь — начать с малого, взять один отдел, на который меньше всего смотрят и который готов к изменениям и сделать там всё правильно, поставить процесс, поставить цели, описать ценности и начать жить правильно. по мере создания ценности и кристаллизации результата — продолжать распространять, при этом доводя до руководителя что "вот оно как должно работать, сравните!"

дальше — переходить от количества к качеству. как только количество групп с правильным подходом, ясными целями и понятными принципами станет весомым или результативным — можно сказать "давайте-ка признаем, что наш подход работает?" и распространить его на всех. на этом этапе понадобится много фасилитаторов и enabling teams. то есть команд, которые помогут и включат процессы и подходы в правильную сторону.

после — ждем, сверяем результат и продолжаем улучшения. не стоит питать иллюзий, что можно в одиночку перевернуть всё в нужно русло или сделать правильно. всегда нужны единомышленники, понимающие что происходит и помогающие. а с саботёрами и воинствующими надо бороться через результат и сравнение их способа и своего.

конечно, не везде можно получить осязаемый результат за вменяемое время. быть может, придется много биться головой, много рубить мельницы и кричать в пустоту. но если получится — это повод для гордости. а если не получится и силы иссякнут — что ж.

меняй компанию, или меняй компанию.

кто из вас ждал запись доклада из Салехарда (yamal.dev) — вот он!
лучше поздно, чем никогда!
там же, на канале есть и остальные видео с конференции, посмотрите их, они интересные!

работа с возражениями

тоже "вопрос из зала")
если в вашей команде постоянно возникают вопросы из разряда "зачем это?" "почему мы?" "неужели это того стоит?" и прочие вещи из разряда основополагающих — вам нужно озаботиться следующим.

во-первых, начните с описания ценностей вашей команды (не нужно лезть в ценности организации, определите их для своей команды).
как их определить? да обсудить с командой что важно для них самих. в разрезе работы, конечно.

для меня всегда важны: открытость, честность и результат. если я описываю ценности — то стараюсь опираться на эти вещи.
например, открытость в выражении мнения — каждый может сказать и будет услышан. открытость в принимаемых решениях — каждый может повлиять на решение и изменить что-то.
честность — можно говорить в разрезе "это дичь" и "вау, ты круто придумал", если это честно) брутальная честность и даже токсичность — это круто, но только когда она аргументирована и подкреплена чем-то.
а чем подкрепить? результатом. если ты только говоришь, но ничего не делаешь — это будет заметно на большой дистанции. а команде важно рефлексировать над своими действиями. значит, над результатом. это помогает не выгорать и оценить то, что мы проделали. результат можно и нужно измерять и демонстрировать, даже выпячивать.

движемся дальше, ценности обозначили, но нужны цели.
цели у команды тоже обязательно должны быть свои и важно — цели могут меняться с течением времени (гораздо чаще, чем ценности). цели — это наши опорные точки, маяки, на которые мы движемся и достигаем их через результаты. цели хорошо обозначать глобально для отдела, локально для группы и супер-локально для отрезков времени (ИПР/квартал/спринт). цели нужно достигать и все силы прикладывать, чтобы цели становились результатом. если цели постоянно не достигаются — надо понять почему и поработать над этим. либо ставить более адекватные и достижимые цели ("встать с дивана и сделать две задачи")

а еще, если у вас прямо обозначены цели — их можно использовать как рычаг воздействия на входящие вам задачи — мол "это не помогает нам достичь цели". но не нужно злоупотреблять и всегда стоит оценить конечный результат от выполненных задач. очевидно, не все задачи ведут к цели, и это нормально: таких задач может быть даже много, но не должно быть столько, чтобы блокировать команду в достижении целей. и индивидуальные цели не должны блокироваться целями команды. ух сложно!

возражения обычно возникают, когда не понятно что это принесет и куда это приведет. под "это" можно понимать что угодно) задачи, практики, подходы, решения.

надеюсь, хоть как-то понятно)

видос со Стачки!
https://www.youtube.com/watch?v=cK3baRL2eH8
кто там хотел про обучение узнать? вот оно!

https://www.youtube.com/watch?v=NEdpIwlcyos

отличное интервью крутой Насти с офигенным Антоном. рад, что работал с ними и вообще хотелось бы, чтобы у Антона все получилось.
спасибо!

и снова "ко мне пришли с вопросом")

вопрос: нужен ли спринт-ревью?

ответ: да, нужен (но есть нюанс, как водится)

что такое спринт-ревью? почему-то сталкиваюсь часто с тем, что путают или даже объединяют его с ретро. или считают что это необязательная процедура и бойкотируют. мол "мне рассказывать нечего, я это все на дейли рассказывал" или даже "я слушать вас не буду, мне всё понятно". так вот — спринт-ревью — это церемония, часть процесса скрама, в которой происходит демонстрация и описание того, что было сделано за спринт (читай — инкремента)

на самом деле, эта практика очень полезна для самого исполнителя и вдвойне полезна для команды.

для исполнителя, польза заключается в формулировании и оформлении (хаха) того, что сделано в рамках задач или вообще за прошедшее время спринта. а для команды — общий контекст, понимание кто чем был занят и оценка своих усилий в масштабе команды.

при этом, очевидно, рассказы должны быть емкими и цельными, без лишней воды, в идеале — с демонстрацией кода/результата, можно даже с презентацией (ppt) и слайдами.

нужно ли на спринт-ревью закрывать спринт? конечно, иначе как мы демонстрируем инкремент, когда задачи еще в работе? после закрытия спринта — можно смотреть на графики велосити/бёрндауна и анализировать поток. потом — спринт-ревью.

хорошим итогом внедренного спринт-ревью будет внешнее демо для стейкхолдеров (и всех желающих). открытый спринт-ревью это кунг-фу высокого уровня.

ну а ретро должен (должно? вообще — должна, это же ретроспектива или встреча) проводиться после всех спринт-ревью и закрытий спринтов. чтобы на ретро идти и обсуждать уже процессные вещи, передавать друг другу спасибо и с чистой головой уходить в заслуженные выходные.

сегодня рубрика «мне рассказали»

с разрешения автора — копипаст без ссылки и раскрытия информации, но текст полезный тем, кто ищет работу или хочет менять сферу.

Итак, холодные майские - это отличный повод поскладывать буквы в слова на тему, как я искал свою первую работу в отрасли.

Задумываться о необходимости практических знаний и росте в коллективе я начал практически сразу после поступления в ВУЗ. Сначала, пока все вокруг было необычно и ново, возникал вопрос, как получится совмещать, а какая загрузка будет по учебе и тд. В октябре - ноябре, когда образовательный процесс вошел в определенный ритм, начал активные поиски.

По ходу поисков настрой менялся от «вот эта стажировка моей мечты, сижу жду ответа» до «загребаю все, что есть». Я выделил следующие основные направления в своих поисках:

1 Стажировки. Скорее всего интересная, рабочая тема, как трамплин для следующего трудоустройства. Многие крупные компании ищут стажеров, чтобы обучить под себя и взять потом на работу. Чем известнее компания, тем выше уровень тестовых заданий и конкурс. Однако, в этом направлении нужно учитывать фактор сезонности. Стажировки - история зачатую летняя, соотвественно поиск стажеров начинается где-то в апреле-мае. До апреля мелькает очень мало приглашений на стажировку. Место обитания подобных вакансий - это сайты компаний, тг-каналы, одногруппники и прочее сарафанное радио. На НН преложений для стажеров мало, видимо как-то связано с какой-то внутренней кухней, хотя может я просто не вовремя искал. Отдельно в этом пункте хочется отметить следующую историю - предложение о стажировке, обучении силами компании с последующей отработкой на определенный срок. В целом, предложение здравое и адекватное по своей сути: компания вкладывается в обучение и было бы здорово получить обратную связь в виде начинающего сотрудника. Меня в этой вакансии не устроили детали: срок отработки, размер возможной неустойки и тд: допускаю, что там все очень классно внутри, но снаружи об этом не узнать, а когда войдешь, у тебя уже будут обязательства перед компанией. Возможно, это неплохая тема для студентов младших курсов бакалавриата, быстрое начало, практические знания от практикующих наставников и большой запас по времени для учебы, ведь еще несколько курсов впереди.
2 Вакансии джунов на НН. У меня сложилось впечатление, что это тупиковое направление. В моем случае не получалось пройти первичный фильтр от подбора персонала, даже после обновления резюме. Причем, по опыту общения на собеседованиях на стажировки, если удается пробиться до живого общения, все складывается достаточно неплохо и положительно. Однако добраться до собеседования не удавалось раз за разом.
3 Рассылка резюме и сопроводительного письма о поиске стажировок по открытым контактам компаний. Вполне рабочий способ. Я составил список всех компаний, о которых что-либо слышал, начал искать их сайты, контакты и рассылать информацию о себе. В ответ часто приходила информация о грядущих стажировках, датах начала отбора и тд, которой не было в открытом доступе на сайте. Однако, тут тоже есть фактор сезонности, как я уже писал в пункте про стажировки.
4 Карьерные форумы, ярмарки вакансий и прочее: этакий живой филиал НН со всеми недостатками. Плюсом является возможности перехватить нанимающих руководителей, но не всегда это получается. К тому же, там достаточно многолюдно, не всегда удается спокойно поговорить, обменяться контактами, резюме.
5 То, что собственно, и побудило все это написать - живое общение на конференциях. Для меня - это было далеко неочевидно и дало основной импульс в поиске работы. Тематическая конференция интересующей отрасли - это возможность вживую, спокойно поговорить с докладчиками, оставить резюме, контакты. Субъективно у этого способа самый высокий КПД в моем случае.

Вместо заключения хочу сказать, что для многих ребят, ищущих первую работу, важно демонстрировать не только свои технические навыки, над которыми, скажем прямо еще предстоит много работать, а еще показывать свою активность, готовность общаться, не бояться подходить и спрашивать, коммуникабельность, в конце концов.

Субъективно, лучше всего это делать лично, вживую, на различных мероприятиях, где есть практикующие эксперты, чем добираться до собеседования через различные отборы.

о дежурствах

инженеры делятся на два типа: те, кто еще дежурит и те, кто уже не дежурит

дежурства как процесс подразумевают, обычно, ответственность за сервис, который ты разрабатываешь и эксплуатируешь.
хорошей практикой является централизованная команда дежурных за все сервисы (она же — ситуационный центр). люди с графиками, панельками, алертами и прочими историями наблюдаемости за всеми системами в целом и сервисами в отдельности.

но, зачастую, сложность систем и обилие нюансов (а так же средний уровень компетентности и возможности вовлечения инженеров ситуационного центра), накладываают ограничения и приходится приходить к системе: "мы это написали, мы за это и отвечаем".

когда команда кроссфункциональна (есть фронты, бэки, базисты, инженеры) — всё просто, мы сервис подняли, мы его и починим. да и вообще сделаем так, чтобы сервис не падал, либо поднимался быстро и незаметно (за 5 секунд, как бутерброд с пола)

а если у нас не stream-aligned team, а complicated subsystem team? тогда начинается жара: мы пишем сервис, им пользуются (почти) все, SLA в кучи девяток, а баланс жизнь-работа — разрушен. сидишь такой в панике, даже если всё хорошо обычно у сервиса, что он стрельнет в самый неподоходящий момент. плюс, центры экспертиз и факторы автобусов, ох, как несладко!

но ладно, допустим, мы разрешили вопрос с тем, как ротироваться в дежурствах (раз в N дней, где N — число членов команды сервиса), но мы же помимо слежения за сервисом еще будем получать потоки входящих вопросов по своим же сервисам, возможно еще иннерсорс запросы (merge requests по кодовой базе), ну и прочие переключения контекста. а дальше больше — это всё влияет на инкремент и отвлечение от спринта. раз в N дней ты бросаешь свои задачи и бежишь разбирать входящий поток обращений, алертов, вопросов.

дааа, задача нелёгкая. давайте сгрузим такие задачи на кого-то?
ага, но только не на ситуационный центр. у ситуационного центра задача только разбираться с алертами и эскалациями — их нужно правильно пройти по ранбуку, вызвать нужных ответственных и создать инцидент-ВКС (если таковой возник).

хорошо, попробуем сгрузить такие задачи на вторую линию поддержки. да, для этого нужно основательно их подготовить, сделав из них почти экспертов в ваших технологиях: написать документацию, провести обучение, описать ранбуки/плейбуки, настроить автоматизацию.

а как бы вы организовали дежурство? или как оно у вас организовано?