Статью на пикабу за авторством yarbush можно почитать тут https://pikabu.ru/story/zachem_ford_krasil_uglyi_na_zavode_6784651

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

upd: Ладно, был не прав, оказывается на слово "invalid" можно кликнуть и прочитать почти-что-user-friendly сообщение

О моделях лидерства.

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

Также и с вопросом лидерства. Теорий лидерства есть великое множество. Я бы хотел поговорить о двух из них. Первая, вполне себе переводимая на русский язык (чего мы, конечно же, делать не будем) - Trait leadership theory. Вторая, чуть менее переводимая на русский - Leader–member exchange theory (или LMX - теория).

Первая заключается в изучении признаков, черт характера и паттернов поведения, присущих людям, которых мы привыкли называть лидерами. Оказывается, если сравнивать черты личности известных лидеров, таких как, например, Махатма Ганди, Стив Джобс, Уинстон Черчилль, с портретом среднестатистического человека, можно обнаружить интересный факт. А именно, все лидеры по одному или нескольким параметрам "превосходят" обычных людей. К таким параметрам, относятся, помимо прочего:
- все черты большой пятерки (это уже относится к модели личности человека https://en.wikipedia.org/wiki/Big_Five_personality_traits):
- Интеллект
- Харизма
- Креативность
- и прочее, прочее, прочее... список можно почитать тут https://en.wikipedia.org/wiki/Trait_leadership

Проблем с таким подходом к вопросу лидерства несколько. Во-первых, у человечества до сих пор нет объективных способов измерения этих показателей. Во-вторых, очень сложно установить какую-либо корреляцию между ~15 признаками и "эффективностью" лидера. В-третьих, мы даже не знаем, являются ли некоторые из этих признаков постоянными. Например, IQ хоть и является более-менее стабильным показателем "интеллекта", но только если рассматривать его на протяжении какого-то длительного срока в десятки лет. Вообще говоря, даже определить, что лидер_1 является более эффективным, чем лидер_2 - это тоже неразрешимая в настоящий момент проблема.

Но существуют и другие теории лидерства, фокус которых смещен с признаков человека-лидера, на то как этот человек взаимодействует с окружающей средой. Одной из таких теорий и является LMX теория.

Объектом изучения LMX мы считаем отношение между 2 людьми - лидером и последователем. Предположение следующие: формат отношений между лидером и "последователем" имеет, во-первых, непосредственное и сильное влияние на эффективность в глобальном смысле, как лидера, так и последователя, а во-вторых, отношение лидера и ведомого также опосредованно влияют на отношения 2 последователей между собой.

При этом, стоит помнить, что раз мы рассматриваем отношение между людьми в классическом рабочем коллективе (1 начальник, n подчиненных), мы должны не просто рассмотреть n связей начальник <-> подчиненный, но также и (n-1)! связей между подчиненными, поскольку качество связи начальник <-> подчиненный имеет непосредственное влияние на качество связи подчиненный <-> подчиненный.

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

В дальнейшем LMX теория начала порождать еще более интересные вопросы, например, "как нам вообще воспитать лидера?". Обратите внимание, что фокус уже сместился с "вы лидер, потому что у вас есть такие-то черты" на вопрос, а как с этим жить, и откуда брать лидеров.

И вишенкой на торте уже являются вопросы создания команд, которые рассматривают все n! связей внутри любого коллектива.

Так что, когда вы в следующий раз увидите рекламу курсов по командообразованию, знайте, эти люди уже дошли до вершины LMX теории и пытаются продать вам кристаллизированные знания ~45 лет работы психологов и социологов. А может быть и нет :)

#shark_recommends
Настало время завести хештег рекомендашек. И сегодня у нас два подкаста мечты!

Подкаст 1. Soft Skills Engineering. https://softskills.audio/. Прекрасный подкаст про 2 мужиков и софт скилах. Особенно большого содержания смысловой нагрузки на минуту ожидать не стоит, но зато количество затейных шутеек превышает все допустимые нормы. Подкаст проходит в режиме вопрос-ответ. За 1 шоу - 2 длинных и размеренных ответа.

Подкаст 2. Programming Leadership. https://programmingleadership.podbean.com/. А вот это уже сурьезный подкаст для сурьезных мушын. Товарищ Marcus рассказывает о своем переходе с позиции инженера в позицию менеджера, а потом и менеджера менеджеров. Подкаст крайне полезен большим количеством разных отсылок к книжкам и работам. Например, пост выше про LMX, я написал после одно из этих подкастов.

А еще я недавно наткнулся на голосование бест-ит-подкаст-евер, из которых я слышал только 1, но собираюсь послушать все. Картинка ниже. Присоединяйтесь!

#shark_recommends
Так как пока дел не в проворот, сделаю затравку!

Скоро будет длиннотекст на тему карьерно-этических перепетий смены места работы. Когда менять, зачем, почему, вот это все.

А пока рекомендашка про HR. Вообще тема человеческих ресурсов богата всевозможными постами, тактиками и соображениями из категории поиска, найма и удержания, но к сожалению, в этом месиве часто нехватает научного подхода и/или статистики.

Но не стоит отчаиваться, ведь на просторах интернета существует сообщество под названием https://xn--r1a.website/hranalitycs!

Большинство постов стоятся по схеме "вот у нас была такая статистика, давайте попробуем сделать из этого какой-нибудь вывод". При этом приводятся реальные ссылки на исследования, смежные посты, источники данных и всю-всю подноготную. Одним словом, крайне рекомендую 🦈

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

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

Во-вторых, кейсы бывают очень разные. Вот, например, история про совершенно восхитительный кейс "мы уходим всей командой" https://www.youtube.com/watch?v=MykpuXt4FVc
Мы будем говорить про самое обычное рядовое увольнение.

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

Итак, пожалуй, начнем.

Давайте построим наши рассуждения вокруг модели, базисом для которой являются два утрвеждения.
Утверждение №1: "Человек работает в компании до тех пор, пока работа в компании удовлетворяет нужды человека".
Утверждение №2: "Компания работает с человеком до тех пор, пока работа человека удовлетворяет нуждам компании".

Рассуждаем дальше. В нашем неидеальном мире полное пересечение потребностей человека и компании встречается редко. Но тем неменее, увольняются не все люди.

Отсюда вытекает следствие №1: Причиной ухода человека из компании, является неполное пересечение потребностей компании и потребностей человека. Но у каждого человека существует субъективное отношение к тому, насколько его множество потребностей должно пересекаться с множеством потребностей компании.

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

Отсюда можно вывести два следствия.

Следствие №2: Если потребности человека и компании не пересекаются (совсем), человек никогда не будет работать в такой компании.
Следствие №3: Если потребности человека и компании полностью пересекаются, человек никогда не будет увольняться.

Сложность №1 здесь заключается в том, что потребности человека - это не только точно измеримые показатели, такие как заработная плата и длина трудовой недели, а также и абстрактные понятия: отношение к человеку, как к специалисту. Отношение коллег человека к работе. Отношение человека к бизнесу в целом и к тому, как этот бизнес строиться (Можно работать в многотысячной компании и уволиться, потому что какой-нибудь CEO, который не знает вас лично, принял решение, которое вас не устраивает)

Сложность №2 заключается в том, что даже потребности, измеримые в конкретных показателях, например заработная плата, не есть величина постоянная. И часто об изменении этой величины компания попросту не успевает узнать. Особенно если компания не прилагает сил, чтобы это узнать.

Таким образом из двух утрвеждений и трех следствий мы получили некоторую простую, но, кажется, рабочую модель - модель пересечение множества потребностей человека и компании.

Имеем очевидное идеальное состояние этой модели - полное пересечение потребностей человека и компании. В таком случае у человека не будет причин для увольнения.

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

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

Как решить эту задачу? Боюсь, что полностью - никак. Но как минимум можно начать выстраивать процессы, которые приближают нас к идеальному миру. Устраивать one-on-one встречи. Интересоваться у людей, что им нравится и не нравится в компании. Позволять людям себя реализовывать в рамках своей роли и, возможно, вне этих рамок. И тогда, возможно, наступит мир-дружда-жвачка и больше ни один человек не решит увольняться.

Фундаментальная и случайная сложность.

Мы живем в мире удивительного количества архитектурных баззвордов и технологий. CQRS, Event Sourcing, PWA, Reactive Applications... список можно продолжать. При этом нам всем хочется писать правильно и на верных технологиях.

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

Но для начала, давайте поговорим о сложности программного обеспечения в целом, т.к. именно сложность является корнем проблемы.
Как завещал товарищ Фредерик Брукс, есть 2 вида сложности при создании программного обеспечения: фундаментальная (essential) и случайная (accidental).

Фундаментальная сложность - это сама суть вашего бизнеса / сферы. Я последние пару месяцев работаю в компании, автоматизирующей рынок логистики. И, должен сказать, сам этот рынок совершенно безумный. Даже самая простейшая перевозка полной фуры из точки А в точку Б - это кипа документов, целая инфраструктура для трекинга, высчитывание ориентировочного времени прибытия/убытия в зависимости от данных геокодинга/пробок/погоды/etc и поверх этого еще пласт персонализированных настроек каждого отдельного перевозчика, кладовщика и клиента. Таким образом, фундаментальная сложность ПО для автоматизации этого рынка - высокая.

Случайная сложность - это все остальное, т.е. разность общей сложности вашего продукта без его фундаментальной сложности. Иными словами, все что не относится к фундаментальному - случайно. Тот факт, что для реализации "личного кабинета, в котором пользователь может прикреплять аватарку" вам нужно развернуть несколько http ручек и еще научиться работать с файлохранилищем - это случайность. Если у вас миллиард пользователей, а значит хранилище огромное и падает, а значит его нужно шардировать и реплицировать, а значит писать для этого код - это тоже случайность, но уже неизбежная.

Иными словами, создать софт с нулевым уровнем случайной сложности решительно невозможно.

При этом очень легко создать софт, обладающий катастрофически высокой случайной сложностью, но довольно низкой фундаментальной. Наша задача - оставить ровно столько случайного, сколько будет достаточно. Или отрезать всё лишнее. Или оставить лишь необходимое.

А это значит, что любое техническое решение должно проходить не только через призму "решает ли это нашу проблему", но также и через призму "является ли это наипростейшим работающим решением". KISS (Keep it simple, stupid)! YAGNI (You aren't gonna need it)! Все эти словечки как раз отсюда.

Но как же так. Как же, если у нас... высоконагруженная система! И нам нужно, чтобы работало быстро! Тут мой ответ такой: если вы достаточно развитая компания, чтобы, во-первых, регулярно производить нагрузочное тестирование, и во-вторых, регулярно анализировать рост этой нагрузки, иными словами, если вы с высокой вероятностью знаете вашу будущее нагрузку - вперед, оптимизируйте. Но оптимизация без минимальной попытки расчитать необходимые объемы - это трата средств бизнеса, инвесторов и выделение лишнего CO2 разработкой. (к слову, скачать яндекс-танк и замерить на примитивном уровне - это вопрос получаса времени)

Таким образом, большая часть попыток сделать special high-grade class of software that makes careful use of relevant software architecture design principles to build particularly customizable and extensible solutions to real problems (https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition) скорее всего в вашем случае - излише. Разве что вы точно знаете, что вы делаете.

(1/2) А - Архитектура

Архитектура - самое неоднозначное слово в IT. В интернетах можно найти десятки определений, при чем половина из них будет друг другу противоречить. Если подумать, то этот хаос можно очень легко объяснить:

1. Первые публичные попытки придумать терминологию для IT начались в 50-60-ые годы. При этом основой для терминологии новой области знаний стало стоительство. Поэтому софт мы "билдим" или "конструируем", его структура - это "архитектура". А мы сами "девелоперы" или в лучшем случае "инженеры". (К слову, факапы сроков при стоительстве дело такое же распространенное, как и при разработке ПО. Возможно, во всем виновата терминология и майндсет, который она приносит)
2. Слово "архитектура" пытается вобрать в себя и структуру продукта, и набор красивых картинок/диаграмм, описывающих его, и стандартизацию способов расширения существующего ПО, и чуть ли не подход к организации команды для реализации архитектуры (Привет, закон Конвея)
3. Делу не помогает наличие всевозможных "архитекторов", которые занимаются совершенно разной деятельностью в зависимости от компании.
4. Придумать определение для слова "архитектура", не использовав другие термины, довольно сложно.

Многие деятели пытались создать хорошее определение, но мне больше всего по душе терминология, введенная Роем Филдингом в 2000 году в своей легендарной докторской Architectural Styles and the Design of Network-based Software Architectures (https://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm). Эта работа скорее знаменита как библия REST, но первая её часть как раз посвящена вопросу архитектуры.

Итак, вольный перевод определений по Филдингу.

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

Фундаментально важная часть этого определения - абстракция времени исполнения! Архитектура - это про то как работает в реальности. Это архиважное замечание, так как оно позволяет делать интересные и полезные выводы. Например, если на картинках у вас "идеальная архитектура", а SLO не выполняются и разработчики жалуются, значит у вас не идеальная архитектура, а архитектор, если такой имеется, не справляется со своими обязанностями.

В данном определении абстракция - это сокрытие конкретных деталей, для идентифицкации свойств.

Программные элементы - это общее название для программных компонентов, коннекторов и данных.

Программные компоненты - абстрактная единица программных инстукций и внутреннего состояния, трансформирующая данные, при помощи предоставляемого интерфейса.

Коннекторы - абстрактный механизм, определяющий способ взаимодействия программных компонентов между собой.

Данные - элемент информации, передаваемый от или к компоненту при помощи коннектора.

Мы получили красивое дерево определений. Архитектура - это рантайм абстракция над элементы, а видов элементов бывает три. Но хотелось бы еще ответить на вопрос как выглядит эта абстракция.

Архитектура определяется конфигурацией программных элементов в их взаимодействии для достижения определелнных функциональных и нефункциональных свойств (так же называется архитектурные свойства).

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

(2/2) А - Архитектура

Осталось ответить на самый важный вопрос... Какая практическая польза от всей этой пачки определений? Дело в том, что нам не так важна архитектура как таковая, как другой термин из той же работы Филдинга - архитектурный стиль. Т.е. конечный набор ограничений множества архитектурных элементов и конфигураций для достижения конечного же набора архитектурных свойств.

Здесь речь о следующем: представьте перед собой бесконечное множество всех возможных архитектурных элементов, вот у вас тут http сервисы, тут RPC, здесь очереди сообщений, а там нереляционные хранилища. Из этого конструктора хочется создать некий новый программный продукт. Как это сделать? С нашими определениями это просто - определить необходимые архитектурные свойства, которые важны нашему продукту. Эти свойства позволят ограничить условно-бесконечный набор элементов до некоторого подмножества, которое мы сможет использовать. При этом, возможно, кому-то уже приходилось в голову создать то что пытаетесь создать вы, и интересующий вас набор свойств можно получить при помощи определенного набора ограничений, называемых архитектурным стилем.

Например тот же Филдинг и REST. REST - это архитектурный стиль, определяемый через следующие ограничения:

1. Клиент-серверная архитектура. Т.е. явное разделение ответственности между инициатором взаимодействия и обработчиком.
2. Отсутствие состояний. Любой запрос должен содержать всю информацию, необходимую для его корректной обработки.
3. Кешируемость. Любое взаимодействие имеет возможность быть закешировано (наличие возможность не означает, что оно должно быть закешировано, но должен быть механизм, который позволяет это сделать)
4. Сложнопереводимое понятие layered system. Т.е. наличие иерархии компонентов, выполняющих разные функции, расположенные таким образом, что каждый компонент видит лишь своих соседей, и не знает, есть ли у этих соседей другие соседи.
5. Единый интерфейс - способ взаимодействия компонентов должен быть одинаковый. Например, все по HTTP, или все по RPC.
6. Code on demand (опциональное ограничение) - сервер имеет возможность расширять функциональность клиента при помощи передачи блоков кода (например, кидать в браузер JS код).

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

Минутка мудрости на тему correlation != causation из гугловский книжки по SRE.

С 2000 по 2009 год наблюдается корреляции между количеством полученных PhD по CS и... Потреблением сыра на душу населения
http://tylervigen.com/view_correlation?id=1099

Ресурс в целом прекрасный чтобы позалипать http://tylervigen.com/spurious-correlations

​​Сегодня вышло продолжение "бестселлера" Google SRE Book: Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems. Электронные версии доступны бесплатно.

Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In this book, experts from Google share best practices to help your organization design scalable and reliable systems that are fundamentally secure.

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

Но сегодня я узнал, что позитивный фидбек — это очень общее понятие для процесса, когда некоторое воздействие A, приводит к увеличению B, что в свою очередь приводит к увеличению A (Сорс, конечно же, википедия https://en.wikipedia.org/wiki/Positive_feedback).

Например, резонанса - это позитивный фидбек. GC spiral of death (это когда из-за увеличения использования памяти в JVM увеличивается частота GC, что увеличивает затраты CPU, что заставляет GC отрабатывать медленнее, что увеличивает затраты памяти и так до OutOfMemoryError) — это позитивный фидбек и из актуального, распространение паники и слухов в обществе — это тоже позитивный фибдек.

The more you know!

Не работал в аутсорсе — не разработчик! (с)

https://medium.com/@MortyMerr/pain-driven-development-79d4cc7391ae

Очень красивая анимация о том, как работает алгоритм консенсуса raft.
http://thesecretlivesofdata.com/raft/
В конце есть ссылка на вайтпейпер https://raft.github.io/raft.pdf

0.5 гугла из 100.

Навеяно прочтением той самой книжки по SRE от гугла. Каждую главу я поражался, насколько же мои проблемы бытовые по сравнению с "при размере гугла, вероятность один на миллион - все равно что происходит постоянно".

Как обычно балансируется трафик? На первом уровне весь ваш набор серверов умещается в запись о DNS. Дальше серверов становится больше, возможно появляется geoDNS, но скорее всего все заканчивается тем, что группы бекендов объединяются под виртуальными IP (VIP), который по Round-robin раскидывает запросы. Работает? Конечно. Но не когда вы обрабатывается по разным источникам от 10% до 40% мирового трафика в зависимости от материка и источника.

Представим что в кейсе гугла нам нужно, чтобы запросы с одного IP летели всегда на один и тот же бекенд. Получается на уровне VIP при балансировке запроса нам нужно держать огромную таблицу всех соединений клиентов к их целевым бекендам. Реализовать это не сложно, так как это по сути и есть NAT (https://ru.wikipedia.org/wiki/NAT), но это огромное количество данных, которые нужно где-то держать, и каким-то образом переносить в случае отказов. Не самое удачное решение, когда количество машин легко переваливает за десятки тысяч, а соединений за сотни и миллионы.

Одно из возможных решений - это похакать на втором уровне OSI пакет, подменив в нем MAC адрес назначения на адрес источника. Бекенд получает такой пакет и, минуя баналсировщик, отправляет его напрямую инициатору запроса. Это называется Direct Server Response. Проблема такого подхода в том, что он требует дописывать (и удалять) MAC адреса новых серверов на балансировщик, что становится затруднительным при таком количество машин.

Конечно с этой проблемой гугл справился решением, которое давным-давно придумали матерые сетевики (в данном случае - Cisco) — магии под названием Generic Routing Encapsulation (https://tools.ietf.org/html/rfc1702). Если в кратце то суть следущая: запихиваем IP пакет в другой пакет, получаем новый пакет IP+GRE. Отдаем этот пакет на бекенд. Бекенд игнорирует часть с GRE, и работает с адресами из IP части, а балансировщик не игнорирует и работает с другими адресами из GRE части. Получается бекенд и балансировщик могут находится хоть на разных континентах. Если адрес можно найти через маршрутизацию - он найдется.

Это все была балансировка до того, как запрос дошел в дата центр. Но ведь теперь его нужно сбалансировать на правильную машину внутри ДЦ! Мы конечно все прячемся за абстракцией, что датацентр - это большой компьютер (https://www.morganclaypool.com/doi/pdf/10.2200/S00193ED1V01Y200905CAC006), но чтобы это действительно было так, необходимо чтобы этот компьютер мог распределять трафик близко к оптимальному. Следует также учесть, что при масштабе гугла не все дата центры одинаковые, и даже внутри одного дата центра могут быть разные по характеристикам машины.

Эту проблему можно решать по-разному, но интуитивно правильное решение очень легко представить. Нужно всего лишь придумать как бы заставить все бекенды возвращать некую цифру "загруженности", которая должна учитывать: текущее количество запросов в единицу времени, количество ошибок в единицу времени и текущую утилизацию в виде CPU/памяти. При наличии такой функции, мы получаем возможность использовать взвешенный Round-robin, где вес - это динамическая характеристика, периодически обновляемая бекендом. При наличии такой характеристики сделать честную балансировку не составляет труда... Жалко что о самое интересной части - как же все-таки подсчитать веса всех этих характеристик гугл-таки умолчал в книжке по SRE :)

Гениально!