#FAIL • Kevlin Henney • GOTO 2022

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

Если же говорить про сам материал, то он покрывает следующие темы
- Time function - работа с временем, особенно с unix timestamp
- NaN - javascript и возврат Not a Number
- Simple testing can prevent most critical failures - как простые тесты могут предотвращать сложные ошибки (автор подсвечивает пользу unit tests по сравнению с интеграционным тестированием)
- Validate your data - про важность валидации данных
- Programming pearls - про формально корректные алгоритмы (формальная проверка которых сложнее самого алгоритма на порядок) и переполнение signed integers:)
- Muphry's law - про ошибки в тексте, когда критикуешь других
- More programming pearls - про то, что обычно ломаются не самые сложные места (где сфокусировано внимание разработчиков), а простые места, навроде валидации входных данных, которым не уделили достаточно внимание, плюс рассказ про историю с ценами на книжку на сайте Amazon
- 101 things I learned in architecture school - интересная история про запуск ракеты Европеским Союзом
- Assumptions - здесь автор вспоминает Парнаса, который еще 50 лет назад писал про модульное software так "The connections between modules are the assumptions which the modules make about each other"
- Configuration error - рассказ про запуск ракеты Роскосмосом с космодрома Восточный с конфигурацией для другого космодрома (что привело к потере ракеты и всех спутников, что она должна была вывести). Тут посыл в том, что конфигурация - это тоже код и его надо тестировать
- GIGO: Garbage in, garbage out - тут расказ про Беббиджа и его WTF насчет вопроса, который ему когда-то задавали "if you put into the machine wrong figures, will the right answers come out?":)
- Excel: Worlds most popular FP - тут автор говорит о том, что Excel - это самый популярный в мире функциональный язык программирования ... и наверное самый подверженный багам из-за врожденных травм:)

#Conference #Postmortem #Management #Software #SoftwareArchitecture #SoftwareDevelopment #Architecture #Fail

От монолита к микросервисам и обратно

Эту историю я рассказывал на South Hub 2023 в формате мини-стендапа:) South Hub — это кэмп для CTO и тех, кто мечтает ими стать, а какие свершения без факапов, поэтому на этой конференции и появилась секция Fuckup Nights. Сама история произошла со мной в самом начале работы в Tinkoff, чуть меньше семи лет назад. Тогда я отвечал всего за несколько небольших команд, которые в сумме состояли из 10 инженеров...

#Postmortem #FuckupNights #SoftwareArchitecture #Architecture #Management

Публичное интервью по troubleshooting для SRE-инженеров на Devoops

Сегодня у меня целых два выступления на разных конференциях. Вечером будет публичное интервью по troubleshooting на Devoops, а днем я расскажу про пути развития senior аналитиков на Flow. Изначально я не планировал такой нагрузки, но выступление на Flow пришлось тоже подвинуть в онлайн:)
Если же возвращаться к интервью на Devoops, то оно посвящено тому как выглядит одно из интервью для SRE инженеров. А выглядит оно как работа в рамках инцидента, где сценарий приблизительно таков:
1. По легенде кандидат и интервьюер работают совместно в SRE-команде. Кандидат исполняет роль Lead, а интервьюер — Junior.
2. Собственно, по той же легенде Lead уезжает на конференцию, а Junior остается дежурить.
3. Дальше происходит инцидент, который они вместе распутывают, так как junior сразу использует "звонок другу" и дальше под руководством лида пытается со всем справиться:)

На публичном интервью я буду выступать в качестве интервьюера, а выступить в качестве собеседуемого согласился Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform.
Спасибо Салиху и надеюсь, что у нас получится интересно:)

#Engineering #SRE #Career #Interview #Processes #Postmortem #Management

Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops

Год назад я рассказывал про этот вид собеседования на конференции, а в этом году пришла очередь провести публичное интервью и показать как оно выглядит на практике. В итоге, на конференции Devoops я проводил это интервью и мне помогал мой коллега, Салих Фахрутдинов, Senior SRE в Tinkoff Origination Platform, который выступал в качестве собеседуемого.

Само интервью началось с нулевого шага, а именно с описания регламента собеседования. По легенде кандидат и интервьюер работают совместно в SRE-команде. Кандидат исполняет роль Lead, а интервьюер — Junior. Собственно по той же легенде Lead уезжает на конференцию, а джуниор остается дежурить. А дальше происходит инцидент, который они вместе распутывают, так как Junior при старте инцидента сделал звонок другу (нашему кандидату) и попросил распутать инцидент совместно.

Подробнее можно посмотреть в статье в моем блоге TellMeAbout.Tech, а также на Youtube канале конференции.

#Engineering #SRE #Career #Interview #Processes #Postmortem #Management #Software #SoftwareDevelopment

Хватит гадать! Девять стратегий для решения любых проблем (Stop Guessing: The 9 Behaviors of Great Problem Solvers) (Рубрика #Management)

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

Если же говорить про подход Нэта, то эффективные решатели проблем демонстрируют девять ключевых поведенческих паттернов:
1. Системный подход к проблеме
Глава 1. Прекращают угадывать и переходят к структурированному анализу
Глава 2. Изучают проблему в деталях, используя все доступные чувства и инструменты для понимания паттерна сбоя
Глава 3. Принимают свое неведение вместо попыток защитить репутацию эксперта, задавая вопросы, которые другие могут считать "глупыми"
2. Точное определение проблемы:
Глава 4. Определяют, какую именно проблему решают, избегая работы над неправильной задачей из-за ложных предположений
Глава 5. Углубляются в основы, изучая как процесс работает, включая базовую науку за ним
3. Независимость от экспертного мнения:
Глава 6. Не полагаются на экспертов как на спасителей, а рассматривают их как помощь
Глава 7. Верят в простое решение, сохраняют упорство и не останавливаются, пока не дойдут до корня проблемы
4. Фактологический подход:
Глава 8. Принимают решения на основе фактов, а не мнений, голосований или субъективных систем
Глава 9. Остаются сфокусированными на цели, измеряя драйверы, которые наиболее непосредственно контролируют проблему

В десятой главе автор рассказывает про то, как выбрать свою методику решения проблем и предлагает свой подход через анализ переменных. Центральная идея его метода заключается в создании дерева переменных - систематическом разборе того, как устроен процесс, и разработке уровней вторичных переменных, влияющих на целевую проблему. Этот подход включает:
- Определение проблемы - точное описание того, что именно не работает
- Детальное изучение проблемы - сбор фактических данных о паттерне сбоя
- Создание дерева переменных - структурированный анализ всех факторов, влияющих на проблему
Грин подчеркивает, что когда у команды есть сотни потенциальных причин, это означает полное непонимание происходящего. Если переменных 200, то истинная первопричина, вероятно, даже не входит в этот список. Эффективные решатели проблем исключают переменные, и каждая исключенная переменная содержит множество подпеременных, которые теперь можно игнорировать.

Мне сама книга понравилась и идеи Грина неплохо так пересекаются с мышление "from first principles". Сходства я увидел такие
- Оба подхода требуют разложения сложных проблем на фундаментальные компоненты
- Отказ от аналогий и предыдущих решений в пользу глубокого понимания
- Вызов существующим предположениям и поиск базовых истин
Но есть и существенные различия, делающие подход Грина более практичным
- First principles начинает с философских основ и фундаментальных законов природы
- Подход Грина более прагматичен и фокусируется на поведенческих паттернах и анализе переменных конкретной проблемы
- First principles больше подходит для инноваций и создания нового, тогда как метод Грина оптимизирован для решения существующих проблем

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

#Engineering #SRE #Interview #Processes #Postmortem #Management #Software