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

Анастасия 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?

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

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

с меня крыса 🐀

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

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

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

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

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

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

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

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

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

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

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

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

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

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