Экстремальное программирование: постановка процесса - Part II (Extreme Programming Applied: Playing to Win)

Этот пост заканчивает разбор книги из начала 2000х, рассказ про которую я начал в предыдущем посте. Здесь я планировал рассказать про шесть оставшихся практик второй очереди, а также дать материалы для дальнейшего изучения. Ну поехали
1) Простой дизайн (Simple Design) - здесь суть в том, чтобы не делать большую архитектуру перед стартом проекта, а проектировать по мере поступления новой информации и требований. Звучит хорошо, но у неопытных ребят это превращается в big ball of mud. В итоге, тут до сих пор есть вопросики о том, а как же правильно проектировать комплексные системы
2) Коллективное владение кодом (Collective code ownership) - коллективное владение кодом внутри команд является стандартом де-факто, а вот контрибьютинг в код соседних команд до сих пор не так тривиален - есть такое направление как innersourcing, про которое упоминают при желании уменьшить ожидания и зависимости от других команд. Основная суть как раз в том, чтобы не ждать соседнюю команду, а самому набацать им кода и влить через процедуру merge request. На этом пути есть ряд организаионно-технических проблем, но bigtech компании как-то справляются с ними:)
3) Приемочные тесты (Acceptance tessting) - суть в том, чтобы фиксировать ожидания заказчика и писать приемочные тесты, которые выступают как фиксация критериев приема задач со стороны заказчика. Сейчас этот подход чуток расширился до критериев готовности по задачам (definition of done), которые должны быть выполнены прежде, чем элемент бэклога (пользовательская история) будет считаться завершенным.
4) Стандарты кодирования (Coding standards) - авторы говорили про стандарты кодирования, которые сейчас автоматизируются на уровне linters. Но если пойти чуть дальше, то стандарты помогают и на уровне использования общих библиотек или стандартизации подходов к проектированию API
5) Метафора системы (metaphor) - интересная концепция про использование метафор внутри системы и общего языка для общения технарей и бизнес-заказчиков. Лет через 5 после выпуска этой книги вышла книга "Domain-Driven Design: Tackling Complexity in the Heart of Software", в которой Эрик Эванс представил концепцию DDD и ввел термин ubiquitous language
6) Сорокочасовая рабочая неделя (40-hour week) - здесь авторы говорят про отсутствие переработок и нормальный work/life balance. Интересно, что уже тогда эта тема была важна и вошла в набор принципов.

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

P.S.
Если этот обзор понравился, то рекомендую почитать книги
- Modern software engineering - это недавняя книга Дейва Фарли, про которую я уже писал. В этой книге Дейв рассказывает примерно про эти же практики, но в приложении к текущему уровню индустрии
- Accelerate - это книга 2017 года от Nicole Forsgreen, Jez Humble и Gene Kim, про которую я уже писал. В этой книге авторы рассказывают результаты DevOps Reports за 5 лет и показывают как инженерные практики помогают бизнесу двигаться быстрее
- Tidy First?: A Personal Exercise in Empirical Software Design (Чистый дизайн. Практика эмпирического проектирования ПО) - недавняя книга Кента Бека, создателя eXtreme Programming, про которую я уже рассказывал. В этой книге Кент подробнее ракрывает суть принципа Simple Design:)
- A philosophy of software design - книга Джона Остерхута, создателя алгоритма консенсуса Raft, про которую я уже рассказывал. В этой книге Джон круто раскрывает про свой подход к дизайну софта и важности инженерных практик

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE

Super Pumped: The Battle for Uber (Битва за Uber) (Рубрика #Management)

Прочитал очередную книгу во время отпуска - на этот раз про историю Uber. Эта компания продемонстрировала силу подрывных инноваций, буквально разрушив стандартный мир таксистов и диспетчеров и построив на осколках новый красивый и удобный мир для пассажиров. Этой революцией руководил Трэвис Каланик, который ценил результаты превыше всего и игнорировал законы, выкручивая руки властям. Эта книга читается как боевик и рассказывает историю удивительно детально, так как Майк Айзек был штатным журналистом в New York Times и писал о технологических компаниях и очень много про Uber, который гремел в 2010х. Пока я читал книгу, то ловил себя на мысли, что это почти готовый сценарий - оказалось, что так думал не только я, но и ребята из Showtime, которые в 2022 году выпустили одноименный сериал. Пересказывать все перипетии книги мне кажется лишним, но вот посмотреть на список ценностей, который сформулировал Тревис, мне кажется интересным. Это позволяет сравнить Uber с другими технологическими гигантами (у Тревиса было 14 принципов как и у Amazon изначально, подробнее про Amazon и его культуру можно почитать в книге "Working Backwards", про которую я рассказывал раньше)

1) Always be hustlin’ (Get more done with less, working longer, harder, and smarter, not just two out of three)
2) Be an owner, not a renter (Revolutions are won by true believers)
3) Big bold bets (Take risks and plant seeds that are five to ten years out)
4) Celebrate cities (Everything we do is to make cities better)
5) Customer obsession (Start with what is best for the customer)
6) Inside out (Find the gap between popular perception and reality)
7) Let builders build (People must be empowered to build things)
8) Make magic (Seek breakthroughs that will stand the test of time.)
9) Meritocracy and toe-stepping (The best idea always wins. Don’t sacrifice truth for social cohesion and don’t hesitate to challenge the boss)
10) Optimistic leadership (Be inspiring)
11) Principled confrontation (Sometimes the world and institutions need to change in order for the future to be ushered in)
12) Superpumped (Ryan Graves’s original Twitter proclamation after Kalanick replaced him as CEO; the world is a puzzle to be solved with enthusiasm)
13) Champion’s mind-set (Put everything you have on the field to overcome adversity and get Uber over the finish line)
14) Be yourself (Each of us should be authentic)

А после низвержения Каланика в 2017 году принципы переписали и их осталось всего 8 (подробнее можно почитать в статье 2017 года).

Если же говорить про книгу в общем, то она мне понравилась. Тревис в ней конечно описан как говнюк, но именно такой человек, который не бежит от драки, и требовался для запуска маховика двухсторонней платформы пассажиры <=> водители. В то время чиновники и стандартные компании такси горой стояли за статус кво, поэтому Тревис срезал углы и добивался результата, но в какой-то момент он перешел черту и начал вредить своей компании. Инвесторам удалось свергнуть его, подготовив целую тайную операцию. Даже уйти красиво ему не дали, слив поминутно всю информацию о свержении Майку Айзеку, который в тот же день все опубликовал в газете:)

Автор завершает книгу предостережением относительно харизматичных основателей технологических компаний навроде Тревиса Каланика (Uber), Адама Неймана (WeWork), Элизабет Холмс (Theranos) или Сэма Бенкман-Фрида (FTX). Эти лидеры умеют продавать видение будущего инвесторам так, что на них находит затмение относительно самой идеи или ее реализации, когда основатель проповедует иезуитское "Цель оправдывает средство".

#Management #Leadership #Bigtech #Processes #BusinessStory

How we use GenAI in SRE (Рубрика #SRE)

Я периодически почитываю статьи Google на тему "Distributed Systems and Parallel Computing" на их сайте research.google. Именно там я нашел статью "How we use GenAI in SRE" с абстрактом вида

Службы Google работают на крупнейшей в мире сети компьютеров. Инженеры по надежности сайтов (SRE) следят за тем, чтобы весь стек был в порядке: центры обработки данных были безопасными, хорошо подготовленными; у нас были резервные механизмы и целостность данных; чтобы убедиться, что мы правильно проектируем наш стек, используя правильные компромиссы в области хранения, репликации и программного обеспечения. Генеративный ИИ — отличный инструмент, который сделает нас сверхэффективными: имея доступ к инструментам для создания наших самых сложных конфигураций, для классификации рисков и событий, для управления большими массивами машин с помощью агентов или для дешевой автоматизации сложных рабочих процессов. В этом докладе будет рассмотрен путь, который SRE начал много лет назад, чтобы стать по-настоящему дисциплиной AI-First, и последние достижения в области инструментов, практик и рабочих процессов.

Эта статья оказалась не статьей, а простенькой презентацией от 20 апреля 2024 года (сама презентация доступна здесь). Из этой презентации можно вытащить не так много нового

1) Тезис про то, как SRE связан с работой AI систем

SRE is crucial component to operate at scale AI systems that are trustworthy, safe and efficient

2) Как SRE помогает AI
- Дизайн распределенных систем - системы, у которых основа завязана на AI, тоже должны хорошо масштабироваться и быть надежными
- Ускорить деплой - новые железные компоненты (GPU, TPU, ...) должны поступать в датацентры и эффективно шедулиться
- Trust & safety - результаты работы систем, основывающихся на AI моделях, должны быть выровнены относительно человеческих стандартов
- Эксплуатация и автоматизация - тренировка моделей и пайлайны для fine-tuning, релизов, откатов и так далее (вообще это можно называть MLOps)

3) Как AI помогает SRE
- Генеративный AI для документации и постмортемов - сохранение документации чистой и актуальной, создание изначальных постмортемов (видимо, рыба с автозаполнением части инфы)
- Автоматизация workflow - агентские процессы служат как workflow runners и выполняют часть функций на проде
- Оценка риска - еще до возникновения инцидента модели могут детектировать проблемы и исправлять часть из них
- Эффективность ресурсов - начиная с температур в датацентрам и до размещения сервисов по доступным машинкам ML модели помогают проду быть более здоровым и эффективным

В итоге, это доклад на хайповую тему, но вот содержание не уходит дальше рассказов о том, что SRE в Google теперь на AI-стероидах и применяется к AI системам:))

#SRE #Management #ML #AI #Processes #SystemDesign #DistributedSystems

Как я решаю сложные задачи или Как от решений в уме я пришел к письменной культуре (Рубрика #SelfDevelopment)

За свои 38 лет я прошел большой путь в этом вопросе. В детстве мне многое давалось легко, еще до школы я начал играть в шахматы, а в первом классе уже побеждал отца. Так я оказался в шахматной секции ДЮСШ, куда я ходил до конца седьмого класса. Там я научился отличию тактики от стратегии, расчету вариантов, а также позиционной игре (тут, кстати, были самые большие проблемы). Шахматы очень структурировали мое мышление и дали следующие перки
- Оценка позиции и проработка стратегии
- Учет конкретных деталей текущей позиции и расчет вариантов
- Умение взглянуть на позицию с позиции оппонента, задача которого не дать тебе реализовать свой план
И все бы хорошо, но я был слишком самоуверенным и ленивым - так я пришел к выводу, что все задачи мне стоит решать в голове. В школе это приводило к тому, что я часто вместо решения уравнения просто писал сразу ответ, при решении стереометрических задач представлял их в голове и тоже писал ответ:) Базовые задачки по физике я решал примерно также. Это привело к тому, что к старшим классам я не мог решать действительно сложные олимпиадные задачи, так как навыка записывать промежуточные шаги у меня не было. В десятом классе я начал учиться в ЗФТШ (заочной физико-технической школе при МФТИ). Это обучение навело меня на мысль, что надо что-то менять. За последние два класса школы я научился писать свои решения ручкой в тетради, а не оставлять в голове - это помогло мне поступить в МФТИ, где я уже строчил лекции и семинары на потоке:)
На третьем курсе университета я начал работать и я продолжать много писать и размышлять о решаемых задачах, но по-настоящему парадигма сдвинулась только тогда, когда я стал руководить людьми. Тогда я понял, что важно не просто описать решение задачи, целевой процесс или нашу стратегию развития приложения, а важно сделать так, чтобы твои коллеги это поняли:) Я начал тренировать эти навыки, но расцвели они уже после прихода в Т-Банк (тогда еще в Тинькофф). Здесь у меня команда и зона ответственности росла быстро и неотвратимо. В какой-то момент я понял, что без выстроенной письменной культуры я быстро закончусь и начал ее практиковать еще активнее - я писал RFC, ADR, планы развития, инструкции, делал автоматизации на базе wiki и макро-репортов:) Суть была в том, чтобы построить систему, в которой информация не замыкается на одном человеке, а доступна всем заинтересованным. Где-то в 2018 году я начал выступать на конференциях и завел блог на Medium, а в 2022 году - в telegram. Сейчас я здесь и пытаюсь по вечерам и выходным писать книгу, которая будет состоять из компиляции моих постов, выстроенных в нужном порядке. Идет это туговато, но если бы у меня не было письменных артефактов из прошлого, то это было бы попросту невозможно:)

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

#SelfDevelopment #Writing #Leadership #Management

Летняя распродажа в издательстве Питер (Рубрика #Sales)

В издательстве Питер очередная распродажа с 12 по 18 августа со скидками в 40%. Для получения этой скидки надо использовать промокод "Лето" при оформлении заказа.

В прошлую расродажу я купил себе 5 книг и одну из них уже прочитал
- Data mesh в действии - тема очень интересна в контексте ухода от стандартного DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale" и поэтому решил почитать другую книгу:)
- Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:) Хотя я эти базовые алгоритмы уже много раз изучал в разных вариациях, но решил, что книга из серии "Грокаем ..." сможет мне объяснить эти алгоритмы еще доступнее:)
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад. Решил посмотреть что авторы добавили по прошествии времени
- Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:)
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT и GPT-4, я ее уже прочел и даже рассказывал в отдельном посте.

#Sales

ЦЕХ 4 - Урок #15 "Превращение рукописи в издание. Эксперт — Светлана Мотылькова" (Рубрика #Writing)

Интересный урок про то, как превратить рукопись в книгу самому или при помощи вашего любимого издательства:)

Основные мысли, которые я вынес из этого урока следующие
1) При работе с издательством надо будет заключить авторский договор - бывают договоры на отчуждение прав и лицензицонные договоры - отличие как при продаже квартиры vs сдачи ее в аренду
2) Лицензионные договоры популярнее и они тоже бывают двух типов: с исключительными правами или неисключительными - неисключительный лицензионный договор позволяет автору заключать такие договоры одновременно с несколькими издательствами
3) Состав договора должен включать следующее: дата и срок действия, преамбула, предмет договора, гарантии авторства и какие права автор передает издательству. Важно подробно перечислить все права, которые автор передает издательству
4) Вознаграждения авторам бывают разные - авансовые для состоявшихся авторов в зачет royalty или только роялти без аванса
5) Условия договора можно обсуждать, задавать уточняющие вопросы и предлагать изменения, которые кажутся ему важными
6) Жизненный цикл рукописи в издательстве достаточно сложен - все направлено на то, чтобы получить на выходе качественный продукт
7) В процессе работы над книгой, автор взаимодействует с литературным редактором, научным редактором, корректором, дизайнером и арт-директором.
8) У автора нет права финального решения по названию книги, обложке, тезисам и всему остальному - надо рассчитывать на профессионализм вышеуказанных специалистов, которые не будут стрелять себе в ногу, ухудшая книгу
9) Количество всяких деталей, которые определяют качество книги, зашкаливает - поэтому издательство не зря берет свой процент за издание книги (ну или вам надо брать риски на себя, организовывать все эти процессы и самому пожинать плоды самиздата)

По итогам этого урока я понял, что мне точно надо работать с издательством - я не чувствую в себе желание заморачиваться со всеми этими вещами, но хочу получить на выходе действительно крутую книгу, которую приятно держать в руках, удобно читать, не зазорно подарить:) Судя по этому курсу ЦЕХ, МИФ в этом плане соответствует моим ожиданиям от издательства:) Мне нравится профессионализм экспертов, ведущих курс, а также работающих в МИФ практикующими редакторами, маркетологами, ...

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Розыгрыш билетов на IT Picnic 17 августа

17 августа в Москве в парке Коломенское пройдет большой ИТ-Пикник, про который я рассказывал раньше. У меня есть 3 билета для читателей моего канала. Чтобы определить кому достанутся билеты, я решил устроить небольшой конкурс - напишите в комментариях темы, которые вы хотели бы, чтобы я разобрал здесь отдельными постами или в видео на Youtube. Авторы самых интересных предложений получат билеты - первых два победителя я определю по количеству лайков под комментариями, а третьим получателем билета будет тот, предложение которого мне понравится больше всего:) Получателей билетов я определю завтра в 16.00 и в личку пришлю им pdf'ки с билетами.

Правила использования билетов такие
1. По одному билету могут пройти 2 взрослых + 2 ребенка
2. Не обязательно двум взрослым приходить одновременно, кто-то может прийти раньше кто-то позже по одному и тому же билету. QR-код считывается два раза.
3. Дети могут пройти на территорию только за руку со взрослыми.

P.S.
Если будет желание встретиться на конференции, то я буду анонсировать последний доклад в шатре Архитектуры и там меня можно будет поймать и поговорить на произвольные темы:)

#Conference #Software #SoftwareArchitecture #SRE

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (Как управлять интеллектуалами: я нерды & гики) - Part I (Рубрика #Management)

Я прочитал эту книгу Майкла Лоппа (Michael Lopp) на английском 5 лет назад, к тому моменту она была уже не первой свежести - пережила 3 переиздания и последнее было в 2016 году. Книга тогда мне понравилась - авторский стиль отличался легкостью и юмором и местами достаточно точно бил в цель. В 2020 году у Майкла появилась книга "The Art of Leadership", которая зашла мне еще больше (я про нее уже рассказывал). А потом прошло время и издательство "Питер" перевело книгу "Managing Humans" под названием "Как управлять интеллектуалами". Я поржал с названия и добавил его в свой виртуальный список книг, которые попали под каток вандалов-переводчиков.

Сейчас при написании своей книги про Engineering management я вспомнил произведение Майкла и решил вспомнить что в нем было хорошего и рассказать об этом вам.

Книга состоит из трех частей:
1. The Management Quiver - здесь автор использует для набора скиллов менеджера метафору стрел и колчана для них. Суть в том, что менеджмент почти всегда подразумевает решение проблем. И ваши навыки являются такими стрелами, которые позволят поразить цель и решить проблему. Одновременно, вы можете пополнять свой колчан, учась у ваших руководителей и коллег.
2. The Process is the Product - лажают все, но именно процессы помогают предотвратить проблемы и катастрофы. Процессы направлены на то, чтобы придать структуру работе и исключить действия, что совершаются наобум. Процессы создают некоторую напряженность между теми, кто создает и теми, кто оценивает. Это легко приводит к бюрократии, бессмысленным совещаниям, конфликтным ситуациям. И автор тут предлагает способы как увернуться от всего этого как Нео от пуль в Матрице
3. Versions of You - здесь автор рассказывает на пальцах о мышлении гиков и о том, как успешно научиться с разными людьми, где каждый человек - это другая версия вас:) А финальные главы этой части посвящены тому, как подготовиться к следующей работе и мирно уйти с текущей.

В следующем посте я расскажу про первую часть книги про навыки менеджеров

#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (Как управлять интеллектуалами: я нерды & гики) - Part II (Рубрика #Management)

Продолжая первый пост об этой прикольной книге, я хотел бы рассказать кратко про первую часть "The Management Quiver", что была посвящена навыкам engineering manager. Автор запаковал это в 21 небольшую главу со смешными названиями, а я вам расшифрую ниже что они значат
1) Не будь мудаком - совет о том, что надо быть человеком для того, чтобы управлять людьми в современном мире. Необходимо постоянно оценивать коллег и определять их потребности и мотивирующие факторы, а не воспринимать их как функции
2) Начальники - это не исчадие ада - автор рассказывает о том, как научиться работать со своим руководителем и предлагает ответить на вопросы:
- В чем состоит работа вашего руководителя
- Откуда он взялся такой (какой у него бекграунд)
- Какие у него слабые места и как он их закрывает
- На каком языке он говорит в общем и как разговаривает именно с вами
- Он действует или только решает (или просто только говорит)
- Каково место вашего руководителя в пищевой цепочке
- Что происходит, когда у него рвет крышу
Ответив на эти вопросы, у вас гораздо больше шанс сработаться с руководителем
3) Стабильные и взрывоопасные - классификация инженеров на взрывоопасных, что драйвят изменения, а также стабильных, что вырабатывают правила и следуют им. Частый жизненный цикл инженера начинается с взрывоопасного, дальше инженер набирается опыта и набивает шишки, а потом становится стабильным:) Эти инженеры не очень ладят, так у них разные ценности и подходы:)
4) Тест Рэндса - это интересный список вопросов для оценки компании, своего места в ней, коммуникаций, стратегии ее развития, своего плана роста в ней
5) Как проводить совещания - начинается глава с классификации совещаний на
- Тактические, где идет обмен инфой и происходит наладка
- Стратегические, где происходит решение сложной проблемы и цель в созидании
А дальше идет речь про культуру совещаний, где у них должна быть agenda, регламент и модерация, а также meeting notes с action points
6) Дурные предчувствия - как настроить свою интуицию на отлов аномалий до того, как они превратятся в проблемы. Автор говорит, что надо научиться чувствовать фальш и не боятся задавать "тупые" вопросы, а также делать deep dive в проблемную область
7) Новейшие сводки. Жалобы. Катастрофа - типы one-on-ones и советы по их проведению
8) Понедельничная истерика - как справляться с истериками коллег. Если кратко, то держите свои эмоции в узде, дайте выговориться коллеге, а потом подведите его в коучинговом стиле к тому, чтобы он сам решил свою проблему
9) Потери при трансляции - что делать при коммуникационном провале по отношению к одному из сотрудников. Здесь автор предлагает постепенно выстраивать взаимодействие заново
10) Распознавание повестки дня - отличная инструкция о том, как понять что происходит на совещании и выжить. Алгоритм выглядит примерно так
- Понять какое у нас совещание: информационное или конфликто-разрешительное (алгоритм нужен только для второго типа)
- Понять роли участников в контексте совещания - кто игрок, а кто пешка (игроки влияют на совещание, пешки просто присутствуют)
- Идентифицировать игроков и понять кто pro, а кто contra
- Выявите проблему
- Дайте contra то, что они хотят (даже если это просто фиксация конфликта на бумаге)
- Если совещание затягивается, то самый заинтересованный уходит писать meeting notes и кристаллизовать то, что уже обсудили

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

#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership

Prometheus: The Documentary (Рубрика #Management )

Интересный получасовой документальный фильм про появление проекта Prometheus в 2012 году внутри SoundCloud, который стал стандартом де-факто для cloud-native приложений.

История развивалась примерно так
- Два ex-googlers (Julius Volz, Björn Rabenstein) устраиваются в стартап SoundCloud и отвечают там за надежность этого решения.
- Инженеры SoundCloud к тому моменту уже сделали свой оркестратор рабочих нагрузок (это было еще до появления K8s)
- Мониторить происходящее внутри этого кластера при помощи statsd и graphite очень тяжело и два ex-googlers сначала пытаются найти приемлемое open-source решение, а потом в свободное время начинают делать мониторинговую систему как была в Google для оркестратора Borg
- Это приводит к плану создания новой мониторинговой системы с pull подходом, time-series базой, а также удобным языком для запросов поверх (PromQL)
- У них это неплохо получается и они промотируют эту систему внутри и она находит хороший прием
- С самого начала код публикуется открыто на GitHub, но потом ребята анонсируют эту систему наружу от имени SoundCloud и другой компании, которая была early-адоптором
- Примерно в это время Kubernetes становится opensource и вокруг него появляется Cloud Native Computing Foundation (CNCF)
- Ребята из SoundCloud общаются с CNCF и дальше Prometheus передается в этот фонд и становится де-факто стандартом в мире K8s
- Эта тесная связка K8s и Prometheus отлично работает вместе и бустит развитие обоих проектов
- В итоге, все идет по плану и теперь у нас есть стандарт де-факто для мониторинга:)

Раньше я уже рассказывал про другие документальные фильмы из этой же серии:
- Kubernetes Documentary
- eBPF Documentary
- Inside Envoy
- Node.js Documentary

#Kubernetes #Film #Documentary #Software #Architecture #DistributedSystems #SRE

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (Как управлять интеллектуалами: я нерды & гики) - Part III (Рубрика #Management)

Продолжая два первых поста про эту книгу (1 и 2), я закончу рассказ про навыки менеджера, которые Майкл Лопп щедро расприсал в первой части книги, что назвается "The Management Quiver"

11) Анатомия мандата руководителя - глава про то, когда и как использовать свое право как руководителя на принятие решения. Классно, если люди в команде могут договориться сами без вмешательства менеджера, но если этого не происходит за приемлемое время, то руководителю надо погрузиться в детали и принять взвешенное решение самому и прокоммуницировать его всем заинтересованным лицам
12) Информационный голод - автор рассказывает как работать с информацией: транслировать в команду актуальную информацию и бороться со слухами. В общем, не стоит практиковать "грибной" менеджмент, где менеджеры держат сотрудников в темноте и скрамливают им булшит.
13) Деликатность, смекалка и молчание - глава про то, что надо быть деликатным в общении, проявлять смекалку (обходить систему) и молча слушать собеседников, собирая информацию для анализа
14) "Начальничий язык" - глава про птичий язык руководителей, который они используют между собой, но вот с инженерами надо говорить на обычном человеческом:)
15) Вы не слушаете! - глава про активное слушание, которое помогает выстроит доверие. Советы примерно такие
- Смотрите прямо в глаза
- Будьте любознательным дурачком
- Обращайте внимание на нестыковки и сверяйте разные версии историй
- Делайте паузы и слушайте собеседника
16) Фред ненавидит офсайды - глава про выездные встречи, которые можно использовать, если
- Нам нужно понять кто мы такие
- Запустить новое направление развития или решить проблему
- Провести стартовое совещание
Автор приводит дельные советы как организовать такие встречи
17) Другой тип DNA - идеалистичный рассказ про горизонтальную оргструктуру, а также про встречи design and architecture, которые напоминают arch review, куда приходят не менеджеры, а крутые инженеры
18) Инженерная ментальность - engineering manger должен помнить о том, как быть инженером и разрабатывать софт (для этого надо писать код)
19) Сотрите их в порошок - здесь автор приводит классификацию лидеров
- Лидер- фокус внутри команды (тактик)
- Лидеры лидеров - фокус на горизонтальных связах внутри организации (микс тактики и стратегии). Связывает уровни воедино. Компании держатся на таких middle managers
- Директор - фокус вовне (стратег)
20) Должности токсичны - глава про карьерные лестницы и вред должностей и грейдов. Позиция автора в том, что они не отражают реальных возможностей людей, которые все разные. Он не предлагает внятную альтернативу, но говорит, что может получиться использовать что-то типа бейджей с навыками, которые описывают людей (мне кажется, что такое не сработает)
21) Говоря "НЕТ!" - важно вовлекать в принятие решений свою команду, а не принимать их единолично. Всегда надо отслеживать свою адекватность и не впадать в режим начальника.

В следующем посте я расскажу про советы Майкла относительно процессов, которые он дал в части 2, которая называется "The Process is the Product"

#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership

IT stand-up - Толя Попко, руководитель группы невизуального тестирования, Яндекс (Рубрика #Humor)

Яндекс теперь делает не только конференции, но и IT стендапы, которых на канале Yandex for Developers недавно появилось 10 штук. Я посмотрел краем глаза несколько видео, но зацепился за это выступление Толи Попко, которое мне показалось действительно смешным и одновременно полезным. В этом выступлении Анатолий отлично обыгрывает тему доступности интерфейсов не только для "условно здоровых людей", но и для людей, "в чей туалет мы ходим, если все остальные заняты". В общем, крутое выступление, рекомендую к просмотру.

#Humor #Software #QA