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

https://www.youtube.com/live/XOa8fv0EAb8?si=oZr5b1pHg3wLSFIs мы в эфире!

подписывайтесь на телеграм канал https://t.me/tatarinfrontend

12 апреля буду на Стачке рассказывать как devops помогает в обучении, а со Стачки поеду на конфу в ИТМО и там расскажу про скрам для инженеров (для будущих инженеров).

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

Анастасия Tech выпустила новый ролик про security с Никитой Ермолаевым, хорошо и многогранно рассказывают про безопасную разработку, SSDLC, appsec, devsecops и прочие темы, о которых многие либо забывают, либо ждут, когда надо будет работать в этом направлении.
https://www.youtube.com/watch?v=h4Za3TOBfx4
подписывайтесь на Настю, пишите комменты, ставьте лайки.

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

моя традиция: в этот день постить эту песню.
https://youtu.be/LRWDHqSq_yo?si=1D5fsjNxIjoEmrbC

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

я на IT_Conf 3.0, да

мы на дискуссии, тут круто

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

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

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

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

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

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

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

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

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

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

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

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

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

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

с меня крыса 🐀