Кстати, не существует единого мнения, должен ли 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”.

✏️ chmod 000 /bin/chmod

# /bin/chmod 000 /bin/chmod

# ls -la /bin/chmod
----------. 1 root root 58584 апр 11 06:35 /bin/chmod

# /lib64/ld-linux-x86-64.so.2 /bin/chmod 755 /bin/chmod

# ls -la /bin/chmod
-rwxr-xr-x. 1 root root 58584 апр 11 06:35 /bin/chmod

На случай важных переговоров, собеседований и всякого такого. (Не повторять на проде просто так!)

#bash

Пришлось мне поковыряться с Graphite. Задача была простая, был Graphite запущенный в единичном контейнере на отдельном хосте с открытыми портами, и нужно было это чудо утащить в DC/OS, сохранив все метрики. Вроде бы ничего сложного - настроить persistent volumes, поднять приложение, скопировать старые метрики, перенаправить приложения, whisper-fetch, и все!

Вдоволь намучившись, но таки победив, я нарвался на главный косяк - Graphite в связке со Statsd использует UDP порт для приема метрик. Наши приложения используют как раз его (чтобы краткосрочный отказ Графита не ломал нам все приложения). Но вот беда - на рынке (да и в Гугле) не существует балансировщика со встроенным service discovery, чтобы обрабатывать входящие UDP дейтаграммы и отправлять их в нужный task.
Ставить статичный порт напрямую на хост, говоря task’у запускаться только на этом агенте - харам (Чего я больше всего боюсь? Что сервер сдетонирует и будет потерян навсегда). Попросить разработку переписать отправку метрик на TCP тоже не вариант - TCP балансировщиков внезапно ТОЖЕ нет!

Единственный адекватный вариант - уехать с Графита подальше (в сторону того же DataDog), забыв этот overengineered ад как страшный сон и живя дальше. Дорого, долго, народ не согласится.

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

Идея для домашнего проекта - написать небольшой балансер на базе Nginx, который мониторит Marathon и делает reload веб сервера, если контейнер отвалился и поднялся с новым портом.

Нарвался вот на такой блаженный пост на Хабре: https://habr.com/post/425413/

Если вкратце - какой-то западный человечек сдетонировал от комментария Нетфликса “Мы не нанимаем младших специалистов” и разродился тирадой на эту тему. Другой человечек разродился ответочкой. Люблю такое по пятницам после обеда. ^^

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

Вернемся к теме. В конторе, на которую я работаю, нет junior’ов вообще. И даже если забить на то, что наша контора считается высокотехнологической (настолько, что мы получаем налоговые субсидии от государства - этакая нидерландская Тезла), контора уже прошла тот период, когда молодой (по опыту, не по возрасту) персонал строил продукт либо по фану, либо осваиваясь в технологии. Последствия этого (технический долг, покрытый архитектурными антипаттернами) мы разгребаем до сих пор. Другой момент - контора была куплена и финансируется охренеть каким энергетическим монстром, так что теперь у нас тут потихоньку пилят энтерпрайз.

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

Однако нанимать джунов все равно нужно. Я, возможно, приеду в Москву и даже прочитаю небольшую лекцию на эту тему на митапе, но если вкратце - вы, возможно, наймете максимально лояльного фирме человека (это только один из плюсов). Лояльнее зеленого джуна, только что получившего корочку бауманки, может быть только Core Dev, который помнит контору еще в гараже.

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

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

Один из учеников довольно креативно сделал домашнее задание: https://telegra.ph/Rehplikaciya-muskula-10-05

С прокурора орнул.

Как же я люблю 21-ый век.

Дорогие читатели, извините за отсутствие контента.

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

Stay tuned, как говорится! Если у вас есть какие-то пожелания и идеи - вы знаете кому писать.

Теперь, когда я отстрелялся, самое время поговорить об экзаменах, сертификации и всем таком.

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

Большинство экзаменов, особенно состоящих из теории и практики, требуют от человека определенной подготовки, и не только по конкретному продукту. Экзамены Cisco содержат вопросы по маршрутизации и сетям в принципе, в Oracle’овых есть вопросы про SQL, про линуксовые нечего и говорить.
Далее, чем выше уровень экзамена (от начального до профессионального), тем сложнее экзамен и тем больше навыков требуется для его прохождения.
Помимо этого, сертификаты служат своего рода минимально планкой для зарплаты. Человек, защитивший CCNP, мог расчитывать на определенный зарплатный минимум в США, ниже которого ему не могли предложить.

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

Конечно, сертификат должен быть ограниченным по времени. Мир не стоит на месте, выпускаются новые версии с этими вашими killer feature и breaking changes.
Oracle 11-ой версии кардинально отличается от 10-ой, а 12-ая версия так вообще не имеет практически ничего общего с 11-ой.

Но вернемся к экзамену, который я недавно сдал - AWS Certified Developer Associate (June 2018 Edition).
Год назад я сдавал архитекторский экзамен (AWS CSA Associate) и вывел простую формулу: если вам попадается вопрос в стиле “Что из изложенного неправда по отношению к сервису Х?” и ниже идут варианты ответов “Сервис Х не умеет У” и ниже “Ничего из этого неправда”, то вариант “Ничего из этого неправда” скорее всего будет правильным. Почему? Потому, что Амазон как бы тонко намекает на свою крутость, и что они могут почти все.

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

И, наконец, самая мякотка - Амазон будет совать в свои экзамены не сколько те темы, которые нужны вашей специализации, но столько те, которые у них идут одним разрядом mission critical service. Среди таких: DynamoDB, SQS, API Gateway, SNS и наша всеми любимая Lambda.
Подобно Apple, убравшей разъем jack и седьмых айфонов и младше, чтобы посадить всех на беспроводные наушники, Амазон активно пихает эти сервисы, и на экзаменах будет проверять ваше знание именно по ним, не давая пространства для расширения кругозора и мышления в сторону других сервисов.

Я не могу раскрывать вопросы, которые мне попались, но среди них был один, где была гипотетическая ситуация: у вас есть база данных, которая со временем стала тормозить, и вопрос заключается в том, что делать. Среди вариантов ответа - выставить ElastiCache перед RDS или же переписать и перетащить данные на DynamoDB. Мозгом вы конечно понимаете, что поднять кластер ElastiCache наименее болезненная задача и для вас, и для ваших коллег, но вы, я уверен, уже поняли какой ответ правильный. 😉

В итоге, можно сказать, что в случае с Амазоном нас ждет то же, что с Apple - он будет двигать тренды, вовлекая в свой vendor lock всех своих пользователей (а значит другие провайдеры будут делать то же самое) и отпугивать тех бедных ребятишек, которые все еще сидят on-prem и не хотят лезть в облако, потому что дорого и много переписывать (а если вы хотите ПРАВИЛЬНО мигрировать в облако, то придется МНОГО переписывать).

Не знаю хорошо это или плохо. Просто это данность.

P.S. А экзамен я, конечно же, сдал и ожидаю сертификат на этой неделе.

Нарвался тут недавно на канал “Архитектор_говорит” (@architect_says).
О том, как я туда попал (и благодаря кому попал, и что я там прочитал) я расскажу позже. (Спойлер: там хаят мои любимые микросервисы, и я просто не могу молчать.)

С автором канала я лично не знаком, наши пути вряд ли когда-то пересекутся, и это хорошо - мы думаем и смотрим на вещи совсем по-разному.
И если я готов игнорировать его мнение про “Монолит против Микросервисов”, последнее (на момент написания этого поста) сообщение я игнорировать не могу.

Итак, прямая цитата:
“У меня между делом спросили, почему это канал так называется.
Ответ очень простой - как понять, что архитектор занят работой? У него губы шевелятся.
Рот закрыл - рабочее место убрал.”

Здесь могла бы быть ваша шутка про работу ртом, но ее не будет.

Я с точностью могу сказать одно: я не пройду собеседование у господина @meowthsli, а он не пройдет его у меня (даже если мы будем разговаривать по темам из TOGAF, игнорируя конкретику вроде построения вычислительных систем на базе Java + Oracle или AWS).

Не нужно читать множественные job desctiption’ы и описания вакансий ИТ архитекторов, Solutions архитекторов, системных архитекторов, да каких угодно, чтобы знать, что архитектор, в первую очередь, проектировщик, исследователь, и в некоторых случаях, прораб и исполнитель.
Почему вы никогда не видели и не увидите junior архитекторов? Потому что их не существует. Эта должность, титул или роль зарабатывается очень много времени, за которое нужно проделать огромный пласт работы, побывав на обеих сторонах баррикад (Ops и Dev разумеется), обладая экспертизой не в одной, но нескольких областях.

Когда вы назначаетесь на проект архитектором, вы должны не только спроектировать, спрототипировать и собрать “скелет” будущего продукта, но и донести до всех (ВСЕХ) stakeholder’ов, исполнителей (разрабов и админов), до бизнеса, если понадобится, почему надо именно так и никак иначе. И это - первая и единственная часть, которая реализуется ртом (а еще с помощью Visio/Lucidchart и несколькими написанными заранее версиями будущего продукта). После этого вы будете продолжать общаться с людьми, но уже по конкретным вопросам и часто меняя структуру продукта по разным причинам.

Считать после этого, что архитектор работает ртом, а его главные job tools это переговорка, листки с бумажками, ментальные шаблоны и прочая менеджерская шушера как минимум странно, как максимум - абсурд.

Есть должности, в которых софт скиллз важнее хард скиллз, но архитекторская не среди них.

Впрочем, мы с Говорящим Архитектором совсем из разных эпох, миров и прочего, и этот пост не несет в себе цели кого-то оскорбить. Автор “братского” канала приглашается к дискуссии, если конечно мой пост до него долетит.