Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up (Рубрика #Management)

Это очередной обзор статьи из серии человеческого подхода к продуктивности разработчиков. Это статья фокусируется на критических аспектах онбординга и наращивания скорости работы инженеров.

Основные моменты этой статьи следующие

1. Вопрос онбординга очень важен - это процесс перехода нового инженера от новичка до продуктивного члена команды. Он важен как для индивидуального успеха, так и общекомандной производительности. Эффективный онбординг может сократить время "разгона" и улучшить долговременную продуктивность
2. Но адаптации инженеров часто мешают стандартные проблемы: недостаточная документация, отсутствие наставничества, неясные ожидания от инженера, а также сложные исходный код проектов. Эти факторы могут задерживать способность разработчика эффективно вносить вклад в работу команды
3. Для оценки качества онбординга надо уметь его измерять. По-факту, это измерение относиться к измерению продуктивности инженеров, но так как нас интересуют только результаты изменений в подходах к онбордингу, то авторы решили мерить не саму продуктивность, а изменения в ней.
4. Предыдущие подходы к ramp-up-time metrics включали сравнение параметров новчиков с опытными инженерами, но авторы этого исследования пошли своим путем, в котором им нужно было избежать сравнения между самими инженерами-новичками (иначе у них появилась бы мотивации геймить метрики и показывать как они здорово онбордятся). В итоге, они решили валидировать метрики-кандидаты относительно восприятия самих инженеров относительно того, насколько они заоонбордились в стандартные инженерные задачи.
5. Авторы исследовали 9 метрик-кандидатов и выбрали для дальнейшего анализа 3, в которых есть прогресс со временем работы и выход на некоторый стабильный уровень. Это метрики
- Active coding time per line of code (LOC)
- Reviewed LOC
- Submitted LOC
Дальше авторы аггрегировали новых инженеров по недельным когортам, а потом начали отслеживать сколько недель потребуется этим метрикам, чтобы выйти на стабильный уровень и оставаться там по-крайней мере 4 недели.
6. Потом авторы запустили опросы для инженеров (что работали меньше 40 недель). Этот опрос прошло порядка 3к инженеров. Вопросы были вокруг 17 стандартных задач, навроде, writing code, reviewing other people's code, running build and tests, finding examples of API use by others at Googe и так далее. Вопросы были про опыт вокруг этих задач в последнюю неделю и было 5 вариантов ответов от "Я не выполнял таких задач", до "Я уже выполняю такие задачи на максимально эффективном уровне по моим ожиданиям".
7. Авторы нашли стат значимую негативню корреляцию между "Active coding time per LOC" и самооценкой эффективности выполнения 15 из 17 задач. А 6 из 17 задач стат значимо были связаны с submitted LOC. Авторы взяли и эту метрику в качестве ramp-ut-time.
8. Авторы рассказали про результаты COVID-19 для ramp-up-time, так как у них данные начали собираться еще до всей петрушки.
- Для инженеров до COVID-19 средняя круизная скорость была в 2.5 раза выше, чем начальная. А для выходящих в COVID она стала всего 1.5x
- До COVID 19 инженеры выходили на стабильный submitted LOC за 12 недель, а после - за 18 недель
9. Авторы думают, что смогут использовать результаты исследования для помощи коллегам, которые запускают образовательные инициативы и треннинги для инженеров внутри компании

Авторы предлагают следующие рекомендации для улучшения онбординга
- Предоставляйте исчерпывающую документацию и четкие guidelines.
- Назначайте наставников или «buddies» для помощи новым разработчикам.
- Реализуйте структурированные программы адаптации с определенными этапами.
- Поощряйте обратную связь от новых сотрудников для совершенствования процессов адаптации.
- Инвестируйте в инструменты и системы, которые упрощают навигацию по исходникам и рабочим процессам.

P.S.
Разводящий пост с обзорами всех статей из серии доступен здесь.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

ЦЕХ 4 - Урок #26 "Работа автора с литературным агентом. Эксперт — Галина Бочарова" (Рубрика #Writing)

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

1. Зарубежом важность литературных агентов достаточно велика, особенно в США и Европе, где они играют ключевую роль. В России их влияние пока ограничено.
2. Но даже на российском рынке виден рост числа агентов - это связано с интересом к переводным книгам, ростом уровня русскоязычных авторов и развитием цифровых платформ, таких как Bookmate.
3. Авторы могут сотрудничать с агентами для продвижения книг, но это не всегда необходимо. Важно выбирать подходящие издательства и правильно готовить рукописи, но это могут делать сами авторы самостоятельно
4. Договоры с издательствами требуют внимательного изучения. Особое внимание следует уделять правам на экранизации, переводы и театральные постановки, которые могут приносить значительный доход.
5. Продажа прав на кино, переводы и зарубежные рынки может быть сложной, но прибыльной. Агенты активно работают с продюсерами и зарубежными партнёрами.
6. Агенты получают комиссию (обычно 20%) от авансов, роялти и других доходов. Дополнительный доход возможен через цифровые сервисы и продюсирование проектов.
7. Издательства могут требовать активного участия автора в продвижении. Агент помогает в этом процессе, но автор также должен быть вовлечён.
8. Агенты готовы работать с новичками, если видят потенциал. Однако это требует больших усилий и рисков.
9. На рынке есть отдельно агенты, а также скауты. Агент представляет интересы автора за комиссию, а скаут работает на издательство за фиксированную оплату.

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ
23. Продвижение автора. Личный кейс
24. Продающие тексты
25. Как стать брендом?

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

How to Learn: Unlocking the Brain's Secrets • Barbara Oakley & Charles Humble • GOTO 2024 (Рубрика #SelfDevelopment)

Интересный подкаст клуба goto, в котором Чарльз Хаммел берет интервью у Барбары Оукли. Барбара автор очень популярного курса "Learning How to Learn" на Coursera. К этому курсу Барбара написала книгу "Думай как математик" ("A Mind For Numbers"), про которую я раньше уже рассказывал. А в этом подкасте было поднято много интересных тем

1. Для разных предметов эффективны разные методы, напрмер, для изучения языков и математики
2. Интересно, что Барбара сама прошла путь от ученого-лингвиста до профессора по инженерии. Книга "Мышление в цифрах", что я уже упоминал выше посвящена методам обучения, подходящим для STEM-дисциплин.
3. Сейчас есть кризис повторяемости результатов исследований в общем, а также исследований в образовании. Барбара приводит конкретные примеры, когда популярные, но неэффективные методы обучения сопровождались научными статьями, результаты которых не удалось повторить
4. Барбара рассказывает о двух работах мозга: сосредоточенный и рассеянный. Для эффективного обучения нужно уметь переключаться между режимами
5. Физические упражнения помогают в обучении, повышая когнитивные способности и успеваемость
6. Тренировки помогают вырабатывать нейротрофический фактор мозга BDNF, который помогает нейронам соединяться друг с другом, а также способствует лучшему усвоению знаний
7. Сон помогает мозгу обрабатывать и закреплять новые знания, а правильное питание, включая растения, орехи и темный шоколад, способствует здоровью мозга.
8. Осознанная практика помогает в обучении - важно практиковать выполнение сложных задач, так как рост на стандартных задачах без вызовов гораздо медленнее
9. Для обучения, как и для работы важна психологическая безопасности, которая означает уважение и способность бросать вызов. В эффективных командах важно бросать вызов и обсуждать неудобные темы. Подробнее можно почитать про проект Аристотель - тут ребята из Google исследовали факторы, что делают команды эффективными и самым важным фактором стала psychological safety
10. Для обучения важно как понимать как работает working и long-term memory. Рабочая память позволяет временно удерживать информацию. Долговременная память хранит информацию надолго. Гиппокамп усиливает память и взаимодействует с рабочей памятью. Гиппокамп усиливает память и взаимодействует с рабочей памятью. Подробнее про типы памяти можно почитать в книге "The Programmer's Brain", о которой я уже раньше рассказывал
11. Гиппокамп быстро формирует и разрушает связи в мозге. Зубрежка перед тестом неэффективна, так как связи быстро исчезают. Повторение с интервалами помогает лучше запоминать информацию.
12. Память хранится в соединениях между нейронами. Эти связи формируют память, как биты в компьютере.
13. Метафоры помогают связывать концепции и понимать новые идеи. А также они помогают лучше их запоминать
14. Барбара рассказывает как она использует AI в обучении через суммаризацию сложных документов перед началом их изучения.
15. Учителя должны обучать студентов эффективному обучению. А AI может помочь им в преподавании, но для этого сами учителя должны быть готовы к новым технологиям
16. Наши знания ржавеют и воспоминания исчезают, если их не использовать. Дендритные отростки могут отмирать, если не использовать навыки. Использование знаний помогает восстановить забытые навыки.
17. Есть еще много областей в исследовании мозга, которые покрыты туманом неизвестного и поэтому тут можно и нужно проводить дальнейшие исследдования, что принесут нам понимание и удивительные результаты

P.S.
Если этот подкаст вам понравился, то могут понравиться материалы из моего предыдущего поста с подборкой материалов на тему работы мозга.

#SelfDevelopment #Brain #PopularScience #Thinking

Вычислительная машина и мозг (The Computer and the Brain) (Рубрика #PopularScience)

С большим интересом я прочитал это научно-популярное исследование, посвященное сравнению человеческого мозга и вычислительных машин. Эта книга не завершена и опубликована посмертно почти 70 лет назад (в 1958 году). Изначально этот материал Джон готовил для Силлимановских лекций в Йеле.

Сама книга до сих пор актуальна, а в свое время была пророческой. Она состоит из трех частей
1) Первая часть посвящена устройству вычислительных машин: памяти, хранимому коду программы, аналоговым и цифровым элементам.
2) Вторая часть исследует мозг с точки зрения нейронных сетей, памяти и логической глубины.
3) Неоформленная третья часть касается выводов о роли кода и языка в системах36.

Основные идеи:
1) Сравнение мозга и компьютера
Фон Нейман рассматривает мозг как вычислительный механизм, сравнивая его с современными ему компьютерами. Он анализирует аналоговые и цифровые аспекты работы мозга и машин, начиная с базовых элементов — нейронов и транзисторов. Автор исследует различия и сходства в архитектуре, памяти, обработке информации и точности работы мозга и ЭВМ. По-факту, он комбинирует теорию информации, начало которой положил Клод Шеннон, а также идею про абстрактный вычислитель от Алана Тьюринга (так называемая машина Тьюринга).
2) Ключевыми вопросы
- Является ли мозг аналоговым или цифровым автоматом? (как мы помним в 50-е годы 20 века знаний о мозге были сильно, чем сейчас)
- Может ли искусственный интеллект достичь уровня человеческого разума?
Фон Нейман, беря за основу идею машины Тьюринга, приходит к выводу, что различия между ними минимальны, несмотря на разницу в строительных блоках.
3) Роль языка и информации
В конце книги поднимается вопрос о том, какой язык использует мозг для обработки информации. Фон Нейман предполагает, что этот язык может быть менее логически строгим, чем привычные математические системы. Мне кажется, что эта часть обрывается затравкой - Джон не смог дописать свои лекции из-за болезни, которую уже победить не смог.

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

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

Подробнее про Джона можно прочитать в книге "Человек из будущего" (она у меня на очереди) или в интересной статье с кратким обзором

#SelfDevelopment #Brain #PopularScience #Thinking #Architecture

Когнитивные науки и технологии: от нейрона к познанию (Рубрика #Brain)

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

Когнитивные нейронауки изучают субстрат и механизмы, стоящие за такими формами сложного поведения, как эмоции, язык, внимание, память и т.д. Таким образом, когнитивные нейронауки интегрирует психологию и нейробиологию. Методы, используемые когнитивными нейронауками, включают в себя экспериментальные парадигмы экспериментальной психологии, неврологии, нейроимиджинговые исследования нервной системы, а также безусловно актуальные в настоящее время подходы поведенческой генетики. Научный прорыв в области сканирования мозга позволил исследователям в области когнитивных нейронаук исследовать работу мозга в режиме реального времени при использовании таких методов, как функциональная магнитно-резонансная томография (ФМРТ), магнитная и электроэнцефалография (МЭГ, ЭЭГ), и инфракрасная спектроскопия.

Поступление будет следущим летом и если у меня не исчезнет интерес к этой теме, то я попробую поступить на эту программу:)

#Brain #SelfDevelopment #Science

Code of Leadership #26 - Interview with Salikh Fakhrutdinov about SRE Growth and SRE Team (Рубрика #Architecture)

В этом эпизоде мы обсудили роль и задачи SRE-инженеров на примере карьеры Салиха Фахрутдинова, главного инженера по надежности в Origination Business Platform Т-Банка. Команда, в которой работает Салих, отвечает за надежность процессов открытия новых продуктов, поддерживает множество сервисов и активно внедряет подход shift left reliability. Салих поделился своим опытом: от первых шагов в программировании до роли главного инженера, рассказал о переходах между компаниями, развитии архитектурных процессов и работе с инфраструктурой. Также обсудили управление командами, дежурства разработчиков, мотивацию для улучшений и важность избыточности в повышении надежности систем.

Мы успели обсудить следующие темы
- Как у Салиха появился интерес к программированию еще во время учебы в школе
- Как он устроился в небольшую компанию и лет за 8 вырос от верстальщика до техдира
- Как Салих искал и нашел себя после прохождения курса для SRE инженеров, а потом перешел в тогда еще Тинькофф
- В чем различие старшего, ведущего и главного инженеров, так как Салих прошел все эти уровни:)
- Как выглядит работа SRE команды, когда дежурит SRE команда, а когда сами разработчики
- Какие стоят цели и задачи перед SRE окмандой
- Что такое shift left reliability и как это делает Салих
- Как использовать избыточность (redundancy) для повышения надежности
- Зачем нужны учения, причем здесь наблюдаемость и где тут архитектура
- В чем различия между менеджерами и инженерами
- Что рекомандует Салих для развития в IT (любите свое дело, учитесь на практике и не бойтесь сложностей!)

🎧 Слушайте выпуск (на podster.fm, Yandex Music), чтобы узнать больше о том, как строить карьеру в IT, развивать навыки SRE и двигать архитектурные процессы.

Полезные материалы
Профиль Салиха на LinkedIn - https://www.linkedin.com/in/free6k
Профиль Салиха в Telegram - https://t.me/free6k
- https://t.me/book_cube/2765
- https://t.me/book_cube/1522
- https://t.me/book_cube/1302

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes

House AI Task Force’s bipartisan report (Рубрика #AI)

В этом декабре вышел интересный документ, подготовленный двухпартийной рабочей группой Конгресса США по искусственному интеллекту (ИИ). Он представляет собой стратегическое руководство для регулирования и внедрения ИИ в различных секторах. Основные идеи доклада можно разделить на несколько ключевых направлений:

1. Секторно-ориентированный подход к регулированию
Рабочая группа рекомендует избегать универсальных регулятивных мер. Вместо этого предлагается разрабатывать правила для конкретных отраслей, таких как образование, здравоохранение, сельское хозяйство и финансовые услуги. Регулирование должно быть направлено на предотвращение рисков и минимизацию вреда, сохраняя при этом инновационный потенциал США в области ИИ1.
2. Принципы регулирования
Доклад выделяет семь ключевых принципов:
- Учет новизны проблем, связанных с ИИ.
- Содействие инновациям.
- Защита от рисков и вреда.
- Усиление возможностей государства через ИИ.
- Применение секторного подхода к регулированию.
- Инкрементальный подход к разработке политики.
- Сохранение человека в центре обсуждений политики в области ИИ.
3. Поддержка инноваций и доверия
Документ подчеркивает необходимость создания благоприятной регуляторной среды для частного сектора, чтобы стимулировать инвестиции и лидерство США в области ИИ.
В процессе разработки доклада учитывались мнения представителей ведущих компаний, таких как OpenAI и Anthropic.
4. Рекомендации по конкретным вопросам
Рабочая группа предлагает решения для следующих направлений:
- Защита данных и цифровая идентификация.
- Авторские права на контент, созданный ИИ.
- Подготовка кадров для работы с ИИ и адаптация образовательных программ под изменяющиеся требования рынка труда14.
5. Инкрементальный подход
Вместо принятия единого закона предлагается делить задачи на небольшие этапы, что позволит гибко адаптироваться к изменениям технологий и контекста их применения.

Интересно было внимательнее почитать часть про Financial Services, что расположена в самом конце доклада и где приведены следующие инсайты и рекомендации

Ключевые выводы
- Искусственный интеллект (ИИ) предоставляет возможность трансформировать сектор финансовых услуг.
- Качество и безопасность данных имеют первостепенное значение для моделей ИИ в финансовых услугах.
- ИИ может расширить доступ к финансовым продуктам и услугам.
- Технологии ИИ уже используются в секторе финансовых услуг.
- Некоторые регуляторы применяют ИИ для выявления несоответствий требованиям законодательства.
- Небольшие компании в сфере финансовых услуг могут оказаться в невыгодном положении при внедрении ИИ.
Рекомендации
- Создавать условия, позволяющие компаниям в сфере финансовых услуг ответственно использовать преимущества технологий ИИ.
- Поощрять и обеспечивать ресурсами регуляторов для повышения их компетенций в области ИИ.
- Сохранять защиту прав потребителей и инвесторов при использовании ИИ в секторах финансовых услуг и жилищного обеспечения.
- Рассмотреть целесообразность использования «регуляторных песочниц», которые позволят регуляторам экспериментировать с применением ИИ.
- Поддерживать принципиальный подход к регулированию, который сможет адаптироваться к быстрым технологическим изменениям.
- Убедиться, что регулирование не препятствует малым компаниям в использовании инструментов ИИ.

#Management #AI #Software #RnD

A Field Guide to Reliability Engineering at Zalando • Heinrich Hartmann • GOTO 2024 - Part I(Рубрика #Management)

Недавно я посмотрел интересное выступление от Heinrich Hartmann, Head of Reliability Engineering at Zalando SE, про их подходы к обеспечению надежности.

Основные идеи доклада следующие:
1) Heinrich отмечает, что он рассказывает про опыт Zalando, компании, что не является бигтехом и не может себе позволить размах Google в плане SRE. Поэтому цель выступления - поделиться знаниями и опытом для малых и средних компаний.
2) У ребят миссия в Zalando есть четко сформулированная миссия у SRE

Mission: Protect the User Experience from operational failures while keeping an eye on Developer Productivity and On-Call Health

Дальше это превращается в Zalando rule of operations:
3) Rule of operations #1: Obsess about user experience
Опыт пользователя должен стремиться к идеалу, но есть метрики productivity и on-call health являются компенсирующими при попытке повышения надежности. Условно, легко быть надежным, если не менять свои системы (это уменьшает productivity) или сжигать людей в дежурствах (это уменьшает on-call health). В итоге, это объединяется в SRE-треугольник: Reliability - Productivity - On-Call Health. Интересно, что по нашим отчетам в рамках фреймворка SPACE в Т-Банке видно, что ниже всего удовлетворенность как раз у SRE инженеров (про сам фреймворк SPACE я рассказывал здесь).
4) Rule of operations #2: Engineering for reliability involves people as much as involves technology
По-факту, надежность это не только про технику, но и про людей. И чем больше компания, тем больше это про людей и процессы:) В итоге, нам надо рассматривать это с точки зрения социотехнической системы. Автор рекомендует изучить для этого системное мышление и рекомендует книгу "Азбука системного мышления" ("Thinking in Systems: A Primer"), про которую я уже рассказывал. Системное мышление позволит научиться учитывать вторичные и третичные эффекты за счет учета feedback loops. Интересно, что feedback loops являются частью другого фреймворка для developer productivity, что называется DevEx, про который я рассказывал раньше
5) Дальше автор вспоминает закон Конвея и мантру "You build it you run it" как руководящие принципы для организации технологической и организационной структуры
6) Автор приводит системную модель Заландо, которую он использует в размышлениях:
- Менеджмет наверху (25 директоров)
- Engineering в середине (250 команд и 3.5к приложений)
- Платформа в основании (k8s, Postgres, Kafka, CI/CD, Observability, ..., 20 команд)
В итоге, сложные задачки ребята пытаются унести в возможности платформы и снять нагрузку с команд. Нарпимер, масштабируемость и планирование ресурсов интегрированы в платформу, или возможность проводить нагрузочные тесты
7) Дальше автор отмечает в чем Zalando хороши: backend и инфра под микросервисы, а также observability этого, а в чем хочется улучшаться: понимание user experience, а также надежность data systems и бизнес-процессров
8.) Дальше автор рассказывает пр алертинг и делится еще одним operations правилом: Rule of operations #3: Alert on user experience ("symptoms") not on server experience ("causes"). Технические директора отсматривают отчеты по дежурствам по своим командам, чтобы отслеживать нагрузку на инженеров. Если нагрузка слишком велика, то требуется с этим разобраться

Продолжение обзора в следующем посте.

#SRE #Architecture #DistributedSystems #Software #Observability

A Field Guide to Reliability Engineering at Zalando • Heinrich Hartmann • GOTO 2024 - Part II (Рубрика #Management)

Продолжая рассказ про выступление Heinrich Hartmann, Head of Reliability Engineering at Zalando SE, хотелось бы рассказать про остальные подходы и принципы, что практикуют ребята

9) Многие отчеты по инфре вшиты в платформу и командам не требуется их собирать руками. K8s, redis, jvm и другие дашборды существуют из коробки, также есть гайдлайны для создания хороших отчетов. Автор рассказывает про RED, 4 Golden Signals, которые они отслеживают
10) Дальше автор рассказыват про observability, которая позволяет отвечать на сложные вопросы относительно вашей системы. Ребята используют OpenTelemetry для стандартизации сигналов приложений, а также у них есть distributing tracing. Подробнее про observability рекомендую глянуть 2 выступления, про которые я раньше рассказывал:
- What Is This OpenTelemetry Thing? • Martin Thwaites • GOTO 2024
- Observability in an Asynchronous World • James Eastham • GOTO 2024
11) В Zalando ребята используют SLO (service level objectives) для работы с reliability и это позволяет
- Понять какую надежность получают пользователи
- Управлять инженерными инвестициями в надежность
- Оценивать влияяние инцидентов
- Тюнить правила алертинга в сторону повышения их качества
У ребят есть отчеты, которые ревьювяться менеджментом относительно соблюдения SLO разными бизнес-операциями.
В общем, это выливается в очередное правило: Rule of operations #4: SLIs quantify the reliabilty of a user experience
12) У ребят выстроен процесс работы с инцидентами и даже есть пятое правило: Rule of operations #5: Past failures lead the way towards future reliability. По-факту, ребята пишут и ревьювят постмортемы, докапываются до root causes, а также ставят и главное выполяют задаки для того, чтобы эти проблемы не повторялись.
13) Напоследок автор оставляет рассказ о том, а как выглядит управление всем этим хозяйством и фоормулирует правило Rule of operations #6: You get what you inspect. По-факту, он рассказывает про еженедельные встречи с директорами и ревью отчетов о надежности

Финализирует автор тем, что приводит все принципы в одном списке (под каждым пунктом которого я тоже готов подписаться)
1. Obsess about user experience
2. Engineering for reliability involves people as much as involves technology
3. Alert on user experience ("symptoms") not on server experience
4. SLIs quantify the reliabilty of a user experience
5. Past failures lead the way towards future reliability
6. Past failures lead the way towards future reliability

В общем, это очень хороший доклад про подход к надежности в технологической компании Zalando.

P.S.
У автора доклада есть отличный личный блог, где есть еще куча интересного материала.

#SRE #Architecture #DistributedSystems #Software #Observability

AI in software engineering at Google: Progress and the path ahead (Рубрика #AI)

Этим летом вышел отличный пост от ребят из Google про их подход к использованию AI в инжиниринге. Основные моменты этой статьи следующие
1) Автор статьи работает в команде, что отвечает за среды разработки ПО, в которых инженеры Google проводят большую часть своего времени, включая inner loop (IDE, code review , code search), а также поверхности outer loop (например, управление ошибками , планирование).
2) Ребята отмечают, что использование AI сейчас повсеместно и влияет на developer productivity и satisfaction, а также измеряется при помощи логов
3) У ребят есть три руководящих принципа, которые они используют при внедрении AI в инженерные продукты

- Prioritize by technical feasibility and impact: Work on ideas wherein both technical feasibility has already been established and high (measureable) impact on engineers’ workflows is expected.
- Learn quickly, to improve UX and model quality: Focus on iterating quickly and extracting lessons learned, while safeguarding developer productivity and happiness. User experience is just as important as model quality.
- Measure effectiveness: As our goal is to increase productivity and satisfaction metrics, we need to extensively monitor these metrics.

Производительность разработки была хорошо описана в статьях
- "Developer Productivity for Humans, Part 7: Software Quality" - я разбирал эту статью раньше
- "Measuring Developer Goals" - я разбирал эту статью раньше
4) Схема применения LLM к софту выглядит примерно так:
- Инженеры используют AI инструменты
- Дальше логи взаимодействия используются для тюнинга фичей под реальные потребности инженеров
- Исторические логи используются для тренировки AI моделей и дальше мы возвращаемся к началу
5) Интересно, что предложения AI ассистента для написания кода поднялись до 37%, а по количеству созданного кода к 50% (по количеству символов). Подробнее про то, для чего применяются LLM в инженерных активностях можно почитать предыдущий пост "Large sequence models for software development activities"

Продолжение обзора в следующем посте.

#Software #AI #ML #Engineering #Processes #DevEx