Ребятки, из тех, кому выслал приглашение, зарегистрировались не все.
Потратьте пару минуток, чтобы пройти по ссылочке, чтобы я успел всех “подтвердить".

Для работы мне нужно было написать один “умный” скрипт по развертыванию наших приложений в DCOS.
Раньше наша система сборки попросту отправляла HTTP вызов в DCOS и фиксировала развертывание, как прошедшее успешно. Если приложение по каким-то причинам валилось или вовсе не поднималось, мы об этом узнавали только из мониторинга.

Другой проблемой были разные конфиги приложений. DCOS использует небольшой spec-файл в формате JSON, и в наших репах лежало по одному (или более) файлику для каждого приложения. От такого тоже нужно было уйти, поскольку разные json-чики порождали комплексную инфраструктуру конфигов, которую нам (Ops) было тяжело отслеживать и управлять.

Написав и протестировав свой скрипт, я выкатил его в промышленное использование, перенастроил пайплайны, да так и оставил все это дело на пару месяцев.

Время шло, мы стали выкатывать не только http микросервисы, но и TCP приложения с несколькими портами, и настало время обновить скрипт.
Когда я открыл проект, я понял всю боль программистов, которые месяц не трогали свой код. Куча велосипедов, костылей и “грязно” написанных строчек вызывали у меня страшную фрустрацию. “Кто мог написать такое говно?!” - думал я и сокрушенно смотрел на имя автора коммита.

Спустя полчаса самобичевания, я познал дзен (наверное уже 6-ой раз за этот месяц) и принялся переписывать свое творение. Через пару часов мой скрипт был переделан, а новая структура создания конфига позволяла добавлять новые “фичи” без надобности переписывать все с нуля.

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

Любите рефакторинг.

Чем больше я работаю в ИТ, тем больше я понимаю, что ничего не знаю.

У нас два build агента, оба клонируют репозитории для сборки, используя ключи SSH.
В какой-то момент у нас случилась проблема с SCM (Bitbucket), и нам пришлось заменить ключи на агентах. В итоге Агент 2 может клонировать репозитории, а Агент 1 не может. Валится по SSH auth.

Полез проверять, ключи одинаковые, с правами на файлики все в порядке. Оказалось в .ssh лежал еще публичный ключ id_rsa.pub, который сервер отправлял как публичную часть, и естественно публичная часть ключа была вообще не с тех степей. Убрал публичный ключ из директории, и все заработало. Почему он берет отдельный файл, и отправляет его как публичную часть ключа - вообще не понимаю.

Я знаю, что ничего не знаю.

Спасибо всем пришедшим на вебинар.

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

Кстати, пока подчищал свой амазоновский аккаунт, нарвался на то, что не могу удалить Private Hosted Zone .local, который создается автоматом, когда мы поднимаете сервис в Fargate. Причина этому - этой зоной “владеет” подсервис ServiceDiscovery (один из компонентов ECS), который не дает вам его удалить. В принципе, логично.

Но если вы больше не используете Fargate и не хотите лишний раз тратить 50 центов, то нужно удалять сервисы и namespace через AWS CLI. Через консоль это сделать нельзя.

Подробнее о том, как это дело подчистить, написано тут: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html

Чуть позже продублирую информацию по тренировочной программе, о которой я говорил на вебинаре и тут https://t.me/manandthemachine/282.

Теперь по поводу программы тренировок (или менторства - кому как проще), о которой я говорил ранее.

Я уже говорил, что обладаю желанием и возможностью помочь своим молодым читателям (и не только молодым, и не только читателям) в карьерном, профессиональном и личностном росте. Целью вебинара было показать свой опыт и навыки, чтобы потенциальные “ученики” могли оценить для себя, нужно им это или нет.

Что я буду делать:
1. Я помогу вам определиться со своими среднесрочными и долгосрочными целями.
2. На базе этого я подготовлю для каждого “ученика” план развития.
3. Этот план развития затем будет обрастать направлениями на прохождение курсов (разумеется онлайн), чтение различной литературы, выполнение всякого рода домашних заданий.
4. Я со своей стороны буду этот процесс регулировать контролировать.

Воспринимайте это как найм персонального тренера для фитнеса.

Чего же я не буду делать (и обещать тоже):
1. Я не буду гарантировать вам трудоустройство во время или после прохождения программы. Я не обладаю административным ресурсом, чтобы проталкивать людей на нужные им должности, равно как и не являюсь авторизованным центром обучения с гарантированным трудоустройством (Хотя буду помогать в подготовке к собеседованию и выполнению технического задания)
2. Делать вашу работу. Я заинтересован помогать вам в решении своих рабочих проблем, но делать это придется вам сами. Я смогу только направить в нужную точку.
3. Я так же не буду вам помогать, если вы сами этого не хотите. Тут, я думаю, очевидно почему.

По условиям.

Программа будет длится либо 6 месяцев, либо 12 с возможностью продления. За 6 месяцев - 20 000 рублей, за 12 - 30 000 рублей.
Способы и расписание оплаты, а так же прочие условия прохождения программы будут обсуждаться с каждым индивидуально.

Заранее предвкушая вопрос “Почему так дорого?” - просто потому, что для плодотворного сотрудничества нужна жесткая мотивация. И практика показывает, что мотивация “рублем” - самая надежная. Отдав левому анониму из Телеграмма 20 или 30 тысяч рублей, вы будете гораздо более мотивированы грызть гранит науки, проходить обучение и развиваться.

Для того, чтобы стать участником, нужно будет отправить мне на почту (thomas.storm@protonmail.com) свое резюме (без указания персональных данных - я не подписывался ни под ФЗ 152, ни под GDPR) и сопровождающее письмо, в котором надо ответить на два вопроса: чего вы хотите достичь, и почему вы этого еще не достигли.


Как я писал ранее - эта программа больше подходит для молодых (с точки зрения опыта, а не возраста) специалистов, которые либо только начали, либо вообще не начали осваивать DevOps.

На данный момент всего свободно 5 мест. Если я пойму, что “потяну” больше людей, я сообщу об этом в отдельном сообщении.

Если есть вопросы - смело пишите.

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

Сейчас, с развитием общих стандартов (a.k.a “Суем Кубер повсюду и переписываем все, что есть, на Golang”), таких проектов в компаниях становится все меньше и меньше. Причины тому просты - то, что вы только задумались сделать, сделали за вас во многих фирмах не один раз. И пусть не все исследования попадают в production, изучать что-то новое всегда полезно (даже если в результате исследования выясняется, что от какого-то продукта лучше держаться подальше).

По умолчанию исследовательские задачи ставятся перед архитекторами или инженерами из R&D групп. Под это дело выделяется определенный бюджет или выдается карт-бланш, резервируются необходимые ресурсы, и люди приступают к изысканиям.
Первое, что попадается на глаза во время исследования - предмет оказывается совсем не rocket science, и вместо полноценного изучения, Proof-of-Concept или Minimal Viable Product делаются по очеркам из интернета и всяких блогов исследователей-энтузиастов.
На выходе получается годная заготовка, которая неожиданно валится во время промышленной эксплуатации.

Во избежание такого, нужно планировать весь проект, словно речь идет не о разведке terra incognita, а о написании новой фичи для бизнеса.
Обычно я разбиваю исследование на следующие этапы:
1. Суть проблемы. Когда запрос на исследование приходит от stakeholder’ов, то входных данных очень мало для подробного анализа. Всегда стоит пообщаться с бизнесом пару лишних раз, чтобы понять какую именно проблему они хотят решить. Даже если к вам приходит СТО и просит рассмотреть переезд с MySQL на PostgreSQL, вне зависимости от компетенций человека надо от него добиться “Почему”.
2. Потенциальные решения. Их всегда должно быть несколько. Если вы решили “запаковаться” в Докер, то нужно выделить несколько систем контейнерной оркестрации под изучение.
3. Составление критериев исследования. Такое чаще всего надо делать, когда вы изучаете инструментарий под одну конкретную цель (например мониторинг). Сядьте с коллегами по цеху, набросайте критерии, поставьте “тяжесть” напротив каждого. Благодаря этому сможете составить стандартизированный сценарий исследования и максимально объективно оценить предмет изучения.
4. Новое должно быть лучше. Именно лучше, а не “не хуже”, иначе вы никогда не защитите свое исследование перед бизнесом. Преимущества нового должны лежать не только в технологической среде, но и экономической - “доход” (или ликвидация риска финансовых потерей за простой) не должна быть ниже стоимости обслуживания (под которую попадает и железо, и поддержка, и лицензии, и человеко-часы на управление).

Опять же, берясь за любое исследование, не стоит “влюбляться” в новый продукт. За несколько лет работы над исследовательскими задачами из моих проектов только 5-10% PoC увидели свет. Оставшиеся были завернуты по причине смены приоритетов, либо были слишком дорогими для внедрения и последующей эксплуатации.
И это на самом деле не плохо! Гораздо хуже, когда в вашей конторе используют хрупкий DCOS, потому что он ну очень понравился разработчикам.

Дорогие читатели, небольшой анонс.

В период с 23 августа по 4 сентября я буду находится в Москве. Если среди ваших кругов планируются какие-то занятные вечерние митапы, дайте знать. Буду непротив на них появиться и послушать умных людей.

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

Я тут для себя сделал вчера 3 открытия.

1. Doom 2016 является не перезапуском, а полноценным продолжением оригинальной дилогии. То есть Doom Slayer это тот самый Doomguy, что объясняет почему он так комфортно чувствует себя на Марсе, только вылезев из саркофага.
2. Оригинальный Doom был настолько пропитан насилием, что был не только запрещен в некоторые странах, но и получил рейтинг M от немало известной организации ESRB. Открытием для меня стало то, что ESRB создали как раз из-за Doom
3. Для популярного в России и СНГ 1С существует скриптовый язык OneScript.

Между “митапами” в Нидерландах и в России, да и вообще встречами с коллегами по цеху есть, все-таки, большая разница.

Зачем люди идут на встречи профессионалов в Нидерах? Чтобы лицом засветить. Развивать свою сеть в надежде отломить себе в будущем кусочек побольше. Сколько я ни гонял по конференциям или митапам, итог везде один - посмотрите на меня, я классный.
Встреча с экспертами в России запоминается другим - она душевная. То есть нет уже понтов в стиле: “А вот у нас так сделано, мы клевые”. Есть смехуечки и курьезы с работы. Эти дебилы, тут идиоты, здесь позвонили, тут я нафиг послал.

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

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

Но не все мне о моем своеобразном отпуске писать, поговорим снова о миграции.

Миграционные проекты могут быть краткосрочными и долгосрочными. Все это зависит от размера компании и продукта, а также от требований по uptime и методов переезда (переписываем продукт или lift-and-shift).

Так, например, наш проект GSMG в виду статуса бета-тестирования мог спокойно «полежать» час-другой, пока я не перенес базу и не запустил backend на стороне AWS.

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

С «кроликом» пришлось вдоволь намучиться, потому что некоторые микросервисы выступали одновременно и producer’ами сообщений и consumer’ами, что усложняло порядок переключения приложений.
В итоге нам пришлось немного пострадать, но этот вопрос удалось закрыть.

Затем мне поставили задачу унести базу на Амазон. Обьем потерянных данных должен быть равен 0, допустимый downtime - 10 минут на отрезке с часу до двух ночи.

Под это дело я задействовал Database Migration Service (о чем я по приезду напишу в Medium), успешно перенес базу, убедился, что репликация работает без проблем (речь идет о тестовом окружении).
И после этого я получаю письмо от руководителя, что проект замораживается на неопределенный срок, потому что CTO малость надоели конфликты в планировании между Ops и Dev. Потрясающе.

По этому поводу хочу сказать следующее.

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

Сделайте свою работу.

У меня все.

Кстати, не существует единого мнения, должен ли DevOps уметь программировать.

С одной стороны, каждый блог или видеокурс по DevOps скажет вам, что программировать необязательно, главное уметь работать с тулингом (Они лукавят и говорят так, чтобы не спугнуть студента).
С другой - в каждой вакансии DevOps просят знать минимум 1-2 языка, если еще и не тот язык, на котором пишут продукт.

Люди, которым программирование не нужно, смотрят на DevOps со стороны Ops, то есть это вчерашние админы, которые освоили нужный инструментарий и умеют разговаривать с разработкой. Вроде бы все правильно, но в DevOps не только из сисадминов приходят, и вчерашний разраб смотрит на DevOps со своего угла.
ИТ менеджеры, добавляющие внушительный список языков в описание вакансии, тоже лукавят. Такие скорее хотят, чтобы нанятый человек не только работал над DevOps составляющей проекта, но и пилил продукт вместе с остальными (Автор лично с таким менеджером встретился на собеседовании в Рамблер).

Однако это все еще не отвечает на вопрос, нужно ли уметь кодить или нет. На мой взгляд нужно, потому что:
1. Не все задачи можно решить с помощью готовых инструментов. Иногда придется писать малюсенький велосипед.
2. Язык продукта стоит знать ради того же SRE. Можно будет потом сделать продукт отказоустойчивым.
3. Знать язык и структуру продукта стоит для понимания, что вы собираете. Это очень упрощает жизнь.

Но есть еще одна, хоть и неявная, причина. Некоторые DevOps’ы очень ответственно подходят к своей работе. Настолько ответственно, что когда ищут что-то для продукта и находят OpenSource решение, то заходят в GitHub проекта и долго его изучают. Как написан, где явные косяки и так далее.

У компаний, особенно небольших, практикующих Agile, очень часто присутствуют проблема с документированием продукта и процессов.

Это распространенная болячка, и в интернете очень много разных How-To о том, как это решать.
Хуже, когда люди ссылаются на Agile Manifesto, дескать, работающий софт важнее документации.

Позволю себе процитировать Манифест: “Working software over comprehensive documentation”

Все, в целом, верно. Вот только речь идет о проектной документации, а не продуктовой или технической.

Вчера довелось попасть на митап по DevSecOps.

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

1. По волшебной статистике, предоставленной в презентации, на 100 разработчиков приходится 10 DevOps’ов и всего 1 безопасник. Чтобы решить проблему understaffing’а предлагается в каждой команде разработки иметь такого убер-программиста с медалькой “Security Champion”. То есть этот разраб умеет не только писать код, но и писать его “безопасно”.

2. В качестве основной ступени внедрения Sec в DevOps предполагается в CI/CD pipeline добавить два новых “шага” - SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing). Основная разница между этими подходами в том, что статический анализ кода проходит по самому, собственно, коду и ищет в нем CVE и прочие косяки с безопасность. DAST же пытается взломать уже запущенное приложение, поэтому DAST держат и как часть тестирования в Build системе, и периодически запускают на Production.

Продолжаю радоваться скорости ребят из AWS.

Сначала они запилили Аврору (собственная разработка, совместимая с MySQL и PostgreSQL), а теперь (точнее не теперь, а в августе) сделали Aurora Serverless.
В чем разница? В том, что главная головная боль в работе с облаком - правильно просчитать ресурсы. “Безсерверная” Аврора дает возможность выбрать минимальные и максимальные пороги по ресурсам и будет выдавать ровно столько, сколько нужно. Радость для каждого ИТ менеджера - сэкономить пару лишних сотен долларов.

Пока это совместимо только с MySQL, но принцип работы схож с обычными AutoScaling группами. Задаете границы ресурсов, и Амазон автоматом докинет ресурсов в допустимых границах по мере необходимости.

Но прежде чем лезть во все новое, надо помнить о такой страшной штуке, как “технический долг”.

Любой более менее опытный инженер не раз сталкивался с ситуацией, когда нужно сделать работу “грязно”. Например, отключить Puppet agent и руками настроить firewall, пообещав себе сделать “как надо” на следующей неделе. Или договорившись делать все строго по Infra-as-Code, создать часть ресурсов под новый проект “руками”. Потому что “временно”. Потому что “сейчас надо дать хоть что-нибудь, поправим чуть позже”.

Кривые конфигурации, забытые и неустановленные обновления, недокументированные изменения - все это копится тяжким грузом, который со временем очень сложно разгрести и проще устроить катарсис, начав все с чистого листа.
От этого никуда не уйти, и небольшое количество технического долга будет вас преследовать вплоть до пенсии. Чтобы как-то жить с этим, можно применять то же “золотое” правило 80/20. Если вы работаете в проектной группе, выделяйте на проект 80% ресурсов и 20 на “выплату” долга.

Кредитором и плательщиком здесь выступаете вы сами, и если пропустите пару “платежей” (и абсолютно неважно по каким причинам), то попадете в кабалу, когда, уже наоборот, 80% времени уходит на решение технического долга и всего 20% на проект.

А менеджер-коллектор с паяльником уже стучится вам в дверь и шлет смски с угрозами.
Для тех, кто дружит с английским и/или Google Translate, есть полезная статейка о причинах, последствиях и способах избежания технического “дефолта”, что в твоем 98-ом: https://www.extremeuncertainty.com/technical-debt-technical-bankruptcy/

Долгое время мне приходилось по-разному изворачиваться, чтобы настроить автоматический redirect с HTTP на HTTPS на балансировщике AWS.
Официальная документация, равно как и разные бложики, советовали следующее: поставить балансировщик прослушивать 80 и 443 порт (HTTP и HTTPS соответственно), а на backend сервере настроить redirect таким образом, чтобы он перенаправлял входящий трафик с 80 порта и на 443-ий.

У такого подхода был один жирный и неприятный недостаток. Допустим у вас есть веб-сервер, на котором вы настроили redirect на HTTPS. На балансировщике стоит “прослушка” на 443 порт с последующим переводом трафика на 80 порт на target group’е. Поскольку SSL терминируется на балансировщике, после него идет самый обычный HTTP трафик. Поскольку ALB так же меняет header’ы, вы рискуете поймать следующую ситуацию: трафик приходит на балансер на 80 порт - балансер пропускает трафик на backend - backend видит, что трафик пришел на http и редиректит на https - трафик снова приходит на балансер на 443 порт - балансер пропускает трафик на 80 порт на бэкенде, терминируя SSL - backend видит, что трафик пришел на http и редиректит на http - трафик снова приходит на балансер на 443 порт… Догадались, что вы увидите в браузере?

Это очень геморойная тема, поэтому 25 июля Амазон наконец-то анонсил адекватное решение (https://aws.amazon.com/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/). Теперь на правиле прослушивания на 80 порту можно просто поставить правило Redirect. Подробнее можно узнать здесь: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-rules

Соответственно помним, что балансировщик должен также слушать HTTPS с правильно установленными сертификатами.

Немного оффтопика вам в ленту.

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

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

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

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

Другой сериал, который похожим образом запал в душу - новая криминальная драма "Озарк" - история финансового консультанта, сбежавшего в небольшой городок в штате Миссури, чтобы (сюрприз!) спасти себя и свою семью от казни бензопилой.
Главный герой Марти Бёрд тоже не дурак. Он "шарит в теме", всеми силами старается избегать рисков и делать все нормально и по закону. Однако в его схеме и структуре столько движущих частей, что раз за разом его попытки сделать все правильно, ломаются о несчётное количество черных лебедей.
Здесь вам и реднеки-героинщики, и нарко-картели, и налётчики-рецидивисты, думающие по модели "дать по шапке и забрать деньги".
Хуже всего, что ГГ начинает втягивать во все это свою жену и детей.

В целом оба сериала рекомендуются к просмотру детям старше 12 лет (наркотики это плохо, всегда) и ИТшникам (как ни планируй архитектуру, инфраструктуру и процессы, всегда найдутся идиоты, которые все превращают в прах и говно).

Навеяло сегодняшним постом в AfterTimes (t.me/theaftertimes/3498).

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

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

Все очень просто и прозаично - сейчас (и в будущем) добавить лишний гигабайт оперативки, терабайт диска и еще одно ядро гораздо дешевле, чем заставить разработку переписывать софт для производительности. Раньше, как вы догадались, серверы стоили дороже, и было ровно наоборот: дешевле переписать, чем накинуть ресурсов.

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

Конечно, можно делать отсылку на охреневший бизнес, пришедший в наш уютный 2018-ый прямиком из 90-х. Вот только таких контор раз два и обчелся (да и те в регионах - в Москве такое уже не практикуют). Всех бандитов либо посадили, либо перестреляли, а кто остался, стал уважаемым бизнесменом.

По сути, в западных конторах сейчас семимильными шагами идет болезнь под названием “диверсификация”. Она может быть гендерной, может быть этнической, но ее суть проста - разбавляем клубок белых привилегированных мужчин людьми другого цвета и пола. В Нидерландах это пока на зачаточной стадии - тут нанимают женщину на должность финансового директора и потом хвастаются, что соотношение мужчин и женщин уже не 0 к 10, а 1 к 9. Прогресс! В Америке с этим и то хуже - нанимают не по достоинствам, а по параметрам, определяемым при рождении. Эти же кадры потом делают свой вклад, за счет проталкивания “веганского четверга”, а продукт как писали цисгендерные членомрази, так и пишут.

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

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

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

По поводу диверсификации хотелось бы сказать ещё вот что.
Что расизм, что сексизм, что гомофобия - проблемы фундаментальные. И как любые фундаментальные проблемы, их решили устранять административно (отсюда и растут ноги у квот по найму и приему в школы и университеты).

С чего вообще это все началось: главный посыл (и это очень любят проталкивать безумные адепты диверсификации), что не стоит упускать талантливого сотрудника только потому что "он/она не такой как все". Если к вам на собеседование пришел выпускник MIT, то какая разница, с кем он любит спать, или какой у него цвет кожи.

Как убедить человека забить на свои бессмысленные принципы? Заставить его ими поступиться административно (через аудиты, штрафы и прочие коммерческие кошмары).

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

Почему произошел Black Lives Matter? Потому что черным американцам надоел полицейский произвол, а Майкл Браун просто стал последней каплей, даже не смотря на то, что его убийство было обоснованным (а как вы поступите, если на вас несётся огромный черный танк под наркотой, намереваясь забить вас до смерти?).

Что верующие в gender gap, что представители BLM, и те, и другие не дружат с фактами и статистикой. Почему убивают черных преступников больше чем белых? Потому что по закону больших чисел - черных преступников тупо больше. Почему существует гендерное неравенство доходов? Потому что женщина выходит на работу ради вспомогательного заработка - основной household зарабатывается мужчиной в семье, и соискательница не заморачивается по поводу своей зарплаты (те, кто заморачиваются, выбивают себе зарплату по рынку, и никакой гэп им не помеха).

Это вовсе не означает, что расизма нет. Он есть: полицейский, черный, белый и бытовой.
Есть и сексизм. И гомофобия.

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

Конечно забавно, что чёрное рабство закончилось 200 лет назад, а образ "женщина=кухня" отсутствует лет так 20, но мы все ещё пережевываем одно и то же.

Будто других проблем в нашем мире нет. (Смотрит на охеревших банкиров и страховщиков)

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