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

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

о дежурствах

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

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

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

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

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

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

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

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

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

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

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

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

хорошие новости тоже клево работают как сплочающее средство.

но в токсичности надо знать меру. важно не скатиться в «у соседа сдохла корова» и плясать на этом. важнее понять как и что каждое изменение привнесет в нашу общую картину.

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

когда у тебя есть с кем обсудить новости — это классно.

ура!
видос с ITConf 3.0!
тут с таймкодом это если хотите на мое лицо смотреть (мой доклад и сразу после — дискуссия)

сегодня, в понедельник, лучшая тема для начала недели))

редко вспоминаются истории, когда ты был без ничего, а потом тебе что-то дали. а если и вспоминаются, то "это само собой разумеющееся!"

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

к слову, я помню зарплаты в черную (в конвертах), которые задерживали, никаких ДМС и даже дей-оффов по важным делам (всё за свой счет) + жесткое логгирование времени работы и письменные отчеты о проделанном за неделю.

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

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

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

ворк/лайф баланс
карьеристы
вспахиватели

и другие хорошие мысли в статье на Кинжале

согласен очень во многом

мем смешной, а мнемоника классная

скажу честно: послушал 0 докладов, зато пообщался с кем хотел и на стенде было супер классно! 100к1 вообще офигенно получается, людям нравится.
впереди тимлид конф, жду вас!

киберсыч ждет вас на стенде СберМаркет

ну всё, теперь я могу рассказать:
я работаю не в СберМаркете, а в Купере.

не думаю, что на меня лично это повлияет, кроме как постоянного «то есть Купер» и привыкания к новому лого, фирменному стилю и домену

а для компании это должно дать что-то вроде свободы и свежих идей)

го на митап, где я буду ведущим?
я чуть было сам не забыл, да мне напомнили)

incident management meetup
11 июля, в 18:00 онлайн! жду вас!

перфекционизм и гибкость

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

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

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

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

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

не сделав ничего — ничего не получишь.

сычане! жду вас онлайн!
мы уже начинаем!

что должно меня сподвигнуть что-то сделать?

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

отложу в долгий ящик (и посты редко выходят).

а потом снова: ну нет, раз второй раз мысль пришла — надо писать! прям бери и пиши! запость и будь что будет.
лучше сделать и жалеть, чем не сделать и жалеть.

сажусь писать, пишу.

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

а потом я: если надо мотивироваться — то это не от сердечка и не душевно. значит из-под палки. хотя нет, вроде это важно.

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

мотивировать меня на движение не нужно, нужно понять, что не всегда есть шаг вперед, не всегда есть смысл, но делать нужно, когда хочется.
а когда не хочется — не нужно))

пятница.