#машины_разное #люди

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

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

Вернемся на 30 лет назад. Типичный сисадмин, в зависимости от размеров и специфики конторы, отвечает за программно-аппаратный комплекс в определенной степени. Если представить себе торт из таких слоев: приложение - зависимости - midlleware (читай, какая-нибудь WebSphere/Weblogic) - ОС - прошивка железа - железо; то сисадмин владеет всем до midlleware.

Затем происходит НЕЧТО, из-за чего сисадмин учится масштабировать свою работу и берет на себя роли build и release инженера, начинает тащить всякие Jenkins’ы с Ansible’ми. Граница "владения" медленно ползет вверх, наш сисадмин чуть ли не сам код уже пишет, а некоторые и пишут!

Затем опять происходит НЕЧТО, и сисадмины на время исчезают. Теперь у нас есть инженер, который управляет какой-то облачной инфраструктурой, суть-то программируемыми абстракциями. Дай мне виртуальную сеть, виртуальную машину, виртуальную оркестрацию контейнеров, виртуальный кластер баз данных - словом, инфраструктура вроде как есть, но ей и управлять особо не надо. Тогда сисадмин, а ныне модный SRE/DevOps инженер может выступать в двух ипостасях.

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

Облачные провайдеры вовсю продают fully managed сервисы; всерьез идут разговоры о NoOps и даже Low Code; машинное обучение подсказывает готовый код; я заношу виртуальное перо над своим блогом, ведь вот она, эта прекрасная индустрия будущего!..

Как вдруг мою виртуальную руку с виртуальным пером нежно хватает незнакомец в маске. На ней красивым шрифтом светится надпись Platform Engineer, и незнакомец, медленно качая головой, говорит: "Еще рано." Я с недоумением смотрю на него, но погодя на меня снисходит озарение. Я снимаю маску с гостя и узнаю в нем того самого Системного Администратора!

ОК, лирику в сторону. По сути, индустрия как могла выживала сисадминов с рынка, но в итоге научила их программировать, работать с потребителями и предоставлять продукты с самообслуживанием для удобства разработчиков.

Раньше сисадмин давал вам проприетарный интерфейс VMware с минимальным доступом к созданию виртуалок в своем пуле ресурсов, а теперь у вас есть красивый удобный UI и куча автоматики, чтобы вам не приходилось думать лишний раз.

Тупиковая ли это ветвь эволюции или еще один виток, покажет история.

#машины_разное

Тонкое искусство наблюдаемости (оно же observability), прошло не один десяток лет, прежде чем заматереть.

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

После SRE научил не просто мерять сигналы, а выработать некий стандарт из 4 золотых сигналов , тот же Брендан Грегг использует метод USE (Utilisation/Saturation/Errors) для выявления проблем с производительностью.

Потом пришли трассировки и структурированные широкие события, и наблюдаемость стала сама по себе отдельной сложной дисциплиной, как, впрочем, бывает с любым витком эволюции любой практики в ИТ.

Если отвлечься от технической части, то наблюдаемость нам нужна, чтобы ответить на вопрос “Оно работает?”, и этот вопрос куда сложнее, чем многие думают.

Автор этих строк помнит активные дискуссии на том же Хабре и тематических чатах времен 2014-2018, когда сильные умы мира сего задавали эти титанически сложные вопросы “А что значит не работает?”, “А что мы понимаем под работой?” или мое любимое “А когда оно у вас в последний раз работало?”.

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

Но я не зря написал про толкования “рабочести” и изменчивость нашей индустрии. Видите ли, система может быть по всем фронтам “здоровой”, значения метрик приемлемыми, пейджер тихим, дежурство спокойным… А система все равно не будет работать! 😱

Вернемся к предыдущему толкованию “работает” - т.е. система выполняет свои функции. Функции, как мы понимаем, получаются из запросов бизнеса в виде ТЗ, историй и чего бы то ни было, но задача системы - выполнять задачу бизнеса. И вот тут может быть функциональный казус, когда система вроде бы и работает, но задач своих не выполняет.

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

Например, если у нас есть определенный SLA на техподдержку, то рабочая система такая: 10 человек завели по жалобе, 10 жалоб создалось, 10 жалоб получили по назначенному специалисту ТП, 10 жалоб разрешилось в рамках SLA. Любое отклонение - вне зависимости от причин - является симптомом нерабочей системы. 🎉

---

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

С наступающим!

#пятничное #новогоднее

Своих дорогих читателей, соратников и друзей, я хочу поздравить с наступающим, а для кого-то наступившим Новым Годом!

Оставайтесь здоровыми и находитесь в кругу близких вам людей и союзников. Пусть 2023 будет к вам благосклонен!

Мирного неба над головой!!

Искренне ваш,
Чел и Маш. :)

#машины_разное

Я посмотрел на The state of open source software и заметил пару очень интересных моментов, которыми хочу с вами поделиться.

Python выбился на второе место среди популярных языков.

Обещания Гвидо ускорить Python не прошли даром, да и высокий тренд на машинное обучение подпитывает популярность языка. Прибавьте к этому растущее количество bootcamp’ов, воспитывающих новое поколение инженеров с нуля и использующих этот язык с его низким порогом вхождения, и получите закономерный результат.

Конторы продолжают инвестировать в open source.

Что не новость, да и хитрость. Такие проекты повышают имидж и привлекают большое количество бесплатной рабочей силы. 🙂

HCL - самый быстрорастущий язык на GitHub.

Вот это очень интересно при условии, что HCL не язык программирования, а DSL. 🙂 Что однако не мешает писать на нем скрипты, судя по его README.

#машины_aws

У меня есть программа, которая выполняет следующее действие:

def pin_lt_version_to_asg(asg, asg_name, lt_name, lt_version):
    return asg.update_auto_scaling_group(
        AutoScalingGroupName=asg_name,
        LaunchTemplate={
            'LaunchTemplateName': lt_name,
            'Version': lt_version,
        },
    )

Мозгом я понимаю, что мой код сделает вызов autoscaling:UpdateAutoScalingGroup, и разрешаю это действие в IAM.

Запускаю код, получаю следующую ошибку:

botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the UpdateAutoScalingGroup operation: You are not authorized to use launch template: myTemplate

Неожиданно! Окей, Гугл, какие еще действия нужно добавить в политику? Беглый поиск привел меня в StackOverflow, где решением было, конечно же, дать EC2FullAccess.

"Вздор!" - подумал я, сходил в документацию и увидел там тоже самое. 🤦‍♂️

#машины_разное

Утечки утечками, а в этом коде еще разобраться надо будет!

Из очевидного вижу статический анализ кода на какие-нибудь CVE + захардкоженные секреты.

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

Безопасникам Яндекса сил и терпения. Разгребать это придется долго, знаю по печальному опыту.

#машины_aws #машины_разное

Моя лента в Твиттере - пачка академиков и технологов, от которых я узнаю всякие оккультные вещи навроде CRDT.

И вот в мою ленту занесло волной превосходный срач дискурс между Риком Хулиханом и Алексом ДеБри, темой которого были транзакции DynamoDB.

Из него я узнал, что:
1. Транзакции не предоставляют настоящий ACID. Item'ы, записанные в транзакции, доступны к чтению до того, как транзакция завершена (Read Commited). Это создает проблемы при конкурентном доступе.
2. Транзакции - дорогая в разработке фича, которой мало кто в итоге пользуется.

По схожей логике я не стал включать транзакции в серию DynamoDB Deep Dive. Неканонично.

Этот спор был особенно интересен тем, что Рик - бывший амазонец, эксперт NoSQL и изобретатель Single Table Design, а Алекс - автор DynamoDB Book.

Как если бы Алексей Миловидов и Брендан Грегг схлестнулись на тему производительности.

#машины_разное

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

Такого рода поиск познакомил меня с CRDT и проектом Automerge. Но для того, чтобы объяснить сначала рассказать, как работают конкурентные записи, и при чем тут Google Docs.

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

В так называемом "коллаборативном" ПО (доски Miro, Google Docs), важно обеспечивать конкурентный доступ без перезатирания данных. В Google Docs используется механизм Operational Transform, который обслуживает транзакции на уровне операций. CRDT же опирается на состояние - то есть вы набили текст в документ, состояние документа зафиксировалось и улетело на сервер. Далее сервер уже сверяет разные состояния от разных авторов.

Чем же это интересно? Тем, что CRDT направлен на децентрализацию и local-first коллаборацию. Его идея - я должен иметь свои изменения в том виде, в котором указал, а дальнейшая резолюция должна быть под моим контролем. Технические реализации CRDT обеспечивают работу не только с центральным сервером, но и децентрализованно.

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

#люди

На Хабре вышла статья Практикума о том, как живется наставникам и ревьюерам.

Если вы учитесь и хотите видать картину "по ту сторону" или рассматриваете работу в ЯП - милости прошу. Мое видение там тоже есть.

#жиза

Как похорошела Москва бюрократия при Собянине Мишустине!

В январе 2023 я приобрел нидерландское гражданство и, согласно миграционному законодательству, должен отказаться от русского паспорта.

С Россией меня преимущественно связывают личные отношения, так что я со спокойной душой приступил к выполнению своих обязательств. Запускать процедуру выхода из гражданства в России мне не хотелось, а значит нужно прогуляться до консульства в Гааге 3 раза, чтобы:
1. Выписаться из отчего дома
2. Забрать справку, что я выписался из отчего дома
3. Подать заявление на выход из гражданства

Задача тривиальная, но запись в консульство еще во времена COVID-19 было тем еще приключением, а с 22-ого года стала практически невозможной. Дровишек в костер подкидывает и местное правительство, проводя сокращение штата русских консулов в Нидерландах... Словом, на момент написания этого поста запись в консульство в Нидерландах невозможна.

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

Здесь надо сделать одну ремарку о бюрократии. В Нидерландах я практически любое действие я совершаю онлайн, авторизуясь с помощью ЭЦП, а визиты в офис миграционной службы нужны только чтобы сдать биометрию или забрать бумаги. С Россией же у меня была стойка ассоциация “собери 10 бумажек из 12 разных мест, приходи в определенный день недели”. Впрочем, с русской бюрократией я дел практически не имел, как переехал.

Так вот, в чем казус: почти все бумаги для выхода из гражданства РФ, кроме справки о выписке, я могу сделать онлайн и в электронной форме с ЭЦП! А вот чтобы уведомить миграционную службу Нидерландов о том, что я вышел из гражданства, мне нужно отправить бумажное письмо с переведенной справкой от консульства! Более того, чтобы запросить отсрочку (!!!) дедлайна, я тоже должен отправить бумажное письмо!

Чья бюрократическая машина теперь эффективнее - вопрос открытый.

#пятничное #люди

Открыл блог про то, "как создавать высокопроизводительные инженерные команды".

"Шаг 1: Наймите топовых инженеров"

Закрыл блог.

#машины_разное

Обещанный пост про блокировки!

Если совсем просто, то механизм блокировок (lock) реализуется с помощью обычной хеш-таблицы/словаря/чего-бы-то-ни-было. Ключом к этому словарю обычно является сам объект блокировки, а значение - некий идентификатор/токен замочка.

Объектом блокировки в данном контексте может быть что угодно. Довольно древний, по современным меркам, storage engine MySQL под названием MyISAM блокирует целые таблицы, а более новый InnoDB - строки. Продвинутый механизм блокировок в PostgreSQL, который задействует snapshot isolation - блокировка назначается на строку, но в определенный момент времени! Записи, в том числе обновления и удаления данных, в таблицах Postgres, работают в режиме append only, заправляя это все крепеньким vacuum’ом, ну или как там это называется, знатоки пусть меня поправят.

Локальная система блокировок существует в памяти СУБД.
1. Подключился к СУБД
2. Запрашиваешь “замочек” на строку Х в таблице У (acquire lock)
3. Получаешь некий токен “замочка” - механизм тебя “запоминает”
4. Производишь запись, “освобождаешь” замок (release lock)

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

Но если вы работаете в смузихлебном стартапе, то скорее всего вы живете в условиях распределенных систем, а значит у вас распределенные хранилища, а возможно и распределенные системы блокировок!

И если вам сейчас показалось, что я несу откровенную чушь - то зря. В SRE книге Гугла в 4-ой главе рассказывается про распределенную систему блокировок Chubby. Другим примером распределенного замочка может быть ситуация, когда вы хотите заблокировать некую сущность в пределах нескольких независимых систем. Распределенный замок может быть реализован и в рамках самой системы, например Redlock в Redis. Мы к этому еще вернемся, но тут важно уточнить, что Redlock это фича для потребителя, а не внутренний механизм для работы с запросами.

Как любая распределенная система создает неприятный головняк, так и распределенные блокировки тоже. Представьте себе следующее: процесс взял замок, начал обрабатывать транзакцию, а потом умер. Мы можем решить это с помощью срока жизни (TTL) замка, но что если процесс не умер, но задержался на срок дольше TTL?

Решается это еще интереснее, и вот тут я хочу поделиться наинтереснейшей статьей от автора того самого Кабанчика. Там вам и про блокировки, и почему Redlock говно. Не потому что Redlock, а потому что в распределенных системах все говно, если хорошенько докопаться.

#машины_разное #машины_aws

История о том, как Amazon Prime, стриминговый сервис, мигрировал часть своего кода с AWS Lambda на монолиты в виртуальных машинах, вызвала пусть и дебильную, но предсказуемую реакцию.

Почему дебильную? Потому что любой, кто работал с AWS, знает, что рантайм Lambda поминутно дороже ЕС2, а serverless сильно дороже на больших мощностях. Serverless стек подходит для маленьких контор с минимальной нагрузкой (считай, не больше 100 запросов в секунду) и инженерным штатом из 3-5 человек, компетенции которых хватает на то, чтобы быстро написать код и запустить.

Все, что тяжелее, решается усилиями очень дорогих SRE/DevOps/PlatformEng, зарплаты которых дешевле расходов на инфраструктуру. Но сейчас не об этом.

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

Выходит, колесо Сансары таки сделало огромный оборот. Такими темпами еще и к частным ЦОДам на собственном оборудовании вернемся и будем правы.

#машины_разное

Насчет смены стратегий, архитектуры и направления, читай "начали за serverless, закончили за монолит", есть важный нюанс под названием "контекст". Можно было бы пройтись по Amazon Prime, но эту историю только ленивый не мусолил. Давайте из моего опыта.

🟢Ситуация 1: CRUD хранилище
Спроектировали систему-хранилище. Модель данных простая до безобразия:

{
UserId: UUID,
ItemId: UUID,
SchemaName: str,
Payload: binary
}

Поле Payload представляет собой закодированный в Apache Avro набор данных, схема которого описана в отдельном реестре. Пользователь может декодировать на стороне сервера - тогда сервер вернет JSON, или на стороне клиента - тогда сервер вернет base64 строку, а там уже пусть клиент сам схему разбирает.

Целесообразность: эффективно хранить данные, максимальная гибкость клиенту. Сервис, предполагается, будет иметь строгую структуру данных и выполнять функции CRUD.

🟡Ситуация 2: CRUD хранилище с внешними интеграциями.

Проходит некоторое время, и появляется потребность помимо записи в базу делать вызовы туда-сюда, дополнять поле Payload новыми данными и класть в базу. Чем городить костыли на текущем сервисе, принимается решение сделать Отдельный Слой Абстракции™, который будет эти вызовы делать.

Целесообразность: иметь отдельный “интеграционный” слой, не выходить за рамки текущего сервиса.

🟠Ситуация 3: CRUD хранилище с внешними интеграциями, динамическими полями и строгой типизацией десериализованных данных.

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

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

🔴Ситуация 4: А какого хрена мы ходим через 3 сервиса, чтобы вернуть одну сущность?! Почему у нас 80 мс на проксирование запросов?! Давайте переделывать в угоду эффективности.

Между Ситуацией 1 и Ситуацией 4 прошло без малого 6 лет. Если бы вы, как и я, устроились в контору недавно, вы бы, как и я, решили, что систему проектировали и проектировали наркоманы и смузихлебы.

Тут надо сделать ремарку и вновь упомянуть моего приятеля Серегу П., словами которого я руководствуюсь: "Мне очень экономит время задавание вопроса самому себе, когда я вижу какую-то дичь: "При каких условиях я сделал бы вот эту ебалу?"

Ситуации с 1 по 3 я описал, опираясь на дизайн документы, предшествовавшие каждому слою. В каждом, повторюсь, каждом дизайне все было логично, потому что контекст был именно такой. Предполагали ли инженеры-архитекторы тогда, во что вырастет система сегодня? Сомневаюсь. Представляют ли они сейчас? Вполне себе да. Для опыта не существует алгоритма компрессии.

#жиза

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

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

Первое подтверждение этому я это увидел в книге Карлоса Руиза Сафона "Игра Ангела", где главный герой, неудачливый писатель, поймавший большой куш и приобретя патрона, говорит своей ассистентке: "Утром садишься и не встаешь, пока не напишешь."

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

К техническому тексту такой совет слабо применим, но я немало интересных тем для канала бездарно просрал, потому что поленился и не написал. Надо исправляться. :)

#машины_aws

К слову о интересных темах - смахнем пыль со старого срача о системах управления облаками, т.е. Infrastructure-as-Code. Так получилось, что я снова изучаю возможности CloudFormation и нарвался на нововведение под названием Language Extensions.

Language Extensions это Template Macros, разработанные AWS. Сами макросы представляют собой блоки шаблона, которые “трансформируются” на лету, делая шаблон динамическим и позволяя с ним химичить, как душе угодно.

Например, AWS SAM это самый, что ни на есть, макрос-сахарок, который абстрагирует под собой неудобства описания serverless ресурсов.

На момент этой записи Language Extensions умеет конвертировать YAML ключи-значения в JSON-строки, включает поддержку Intrinsic Functions в - наконец-то - Update/DeletionPolicy, и с какой-то целью добавляет новую функцию Fn::Length.

Что привлекло мое внимание, так это обсуждение новых фишек этой разработки, а именно вот эта ветка. Да, вам не показалось, мои дорогие ненавистники многострочных шаблонов. В CFN собираются внедрить циклы. Возможно, затем и придумали Fn::Length.

При чем здесь срач, скажете вы? При том, что львиная доля холиваров CloudFormation vs Terraform vs CDK vs Pulumi нередко сводились к тому, что последние 3 инструмента могут использовать цикличность для описания ресурса один раз, а создания многажды, а мой любимый целофан - нет. Поэтому, создавая VPC с 6 подсетями, 3 публичными и 3 приватными, вы 6 раз описывали подсеть, 6 раз описывали ассоциацию таблицу маршрузитации с подсетью, и неизвестно сколько еще дубликаций вам пришлось бы сделать позднее. Шаблон становился огромным набором копированного дублированного кода, который не хочется ни читать, ни тем более обслуживать.

Наконец-то за эту проблему взялись сами владельцы сервиса. Это создает надежду, что сервис живет и не станет полумертвым backend’ом для CDK. А может и станет, кто ж его знает.

#люди

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

Пресловутая “мудрость” появляется, как ни странно, вместе с “сеньорской заебанностью”, когда молодой энергичный заряд постепенно ослабевает, и инженер становится… медленнее. Меньше отправляет pull request’ов в день по сравнению с коллегами, меньше производит дизайн документов, тише ведет себя на встречах и так далее. Это вовсе не значит, что инженер потерял в производительности! Скорее инженер понимает, что здоровье у него одно, опыта у него о-го-го, а 25-летних людей по скорости переплюнуть просто невозможно.

Но причинять пользу предприятию надо, и инженер начинает работать эффективно. Находит дешевые и быстрые имплементации или вообще избегает их - ведь лучше всего работает тот код, который не написали! Делегирует задачи, опираясь на сильные стороны своих коллег (про это расскажу отдельно), доверяет им принятие решений в определенных областях и этапах; выбивает у своего руководителя человеческие ресурсы, чтобы не тянуть проект в одиночку; и начинает все чаще задавать нелюбимый всеми вопрос “А зачем?”. Инженер уже не следит за бесконечным потоком новых фронтенд фремворков и очередных витков эволюции в индустрии, потому что он уже опоздал их изучать, да и они все равно каждую неделю новые.

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

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

#анонсы

4-ого июля буду выступать на HighLoad в Сербии, рассказывая о том, как можно сделать Redis строго-консистентным в кластерном режиме.

Буду рад встретиться очно с коллегами, кто окажется там же в те же дни. 🙂

#люди

Питер Друкер, известный экономист и автор множества произведений в области управления, в своем труде The Effective Executive дает следующий карьерный совет: “Build on strengths, not weaknesses.”

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

Что же касается самого совета, то он полезен не дебютантам индустрии, но опытным кадрам, которые спустя Х лет решили сменить свой карьерный курс. Рекомендую не выбрасывать за борт накопленный багаж знаний и опыта.

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

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

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

#машины_разное

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

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

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

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