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

https://habr.com/ru/company/raiffeisenbank/blog/458420/

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

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

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

Эту идею подхватили мамкины стартапы, где инвестор заинтересован не сколько в продукте как таковом, а в том, чтобы увеличить стоимость продукта/стартапа максимально быстро (если быть точным - быстрее конкурентов, пока рыночек не порешал).

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

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

"Without requirements or design, programming is the art of adding bugs to an empty text file." (с) Louis Srygley

Очень крутое чтиво: https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/

https://aws.amazon.com/blogs/aws/amazon-eventbridge-event-driven-aws-integration-for-your-saas-applications/

А вот это очень и очень круто.

Представьте, что у вас Zendesk, и вам нужно выполнить какую-то логику в Амазоне при создании нового тикета.

Или у вас DataDog отправляет event (например оповещение, связанное с информационной безопасностью), и вам нужно срочно вывести машину из кластера в отдельную песочницу для расследования.

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

Однако все еще есть те, кто очень хочет иметь титул “Старший” напротив своей должности.
Когда мы открыли вакансию амазонщика к нам в контору, она изначально называлась Senior Cloud Solutions Architect. Почтовый ящик наших рекрутеров забомбили резюме специалистов из Индии и Ближнего Востока: людям очень хотелось переехать, да еще и в роли Царя Царей.

Откликались, конечно же, точно такие же Senior SRE/DevOps/Cloud/Systems инженеры и архитекторы. Эти же кадры не могли объяснить мне версионирование в S3 и отличие эфемерных хранилищ от персистентных.

Забавно то, что количество белых соискателей было на очень низком уровне. На 20 человек из Бангалора приходился 1 нидерландец.

После того, как я попросил изменить название должности на нейтральное Cloud Engineer, количество откликов из стран востока резко упало, а вот количество соискателей из ЕС и Северной Америки стало расти.

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

Но вчера небезызвестный @SinTeZoiD скинул в группу ссылку на совместный подкаст с LinkMeUp, где обсуждали такие животрепещущие темы, как Kubernetes, Docker, DevOps и SRE. Шел 2019-ый год.

За 3 часа подкаста (я успел приготовить ужин, съесть ужин, переварить ужин, помыть посуду и узнать внезапно, что Service Mesh это хипстерский Enterprise Service Bus (Миша, серьезно?)), ближе уже к концу начался настоящий замес - почему DevOps инженеров не существует.

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

Если вы в индустрии уже достаточно давно и следите за трендами, которые задают смузихлебы из креативных коворкингов, то вы знаете, что DevOps расшифровывается очень просто: Development and Operations. Такой расшифровки достаточно, чтобы все понять.

Отсюда же появляется осознание, что DevOps инженеров не может быть в природе. Если мы берем за правило, что DevOps это культура, то откуда возьмется Культура Инженер?

Если же мы берем простой акроним, то тем более не может быть Разработка и Операции инженер.

Топящие за существование DevOps инженеров любят применять следующий прием: дескать DevOps инженер занимается настройкой работы CI/CD (кто тогда Release Engineer?), работает и настраивает Kubernetes/Mesos/Nomad (кто тогда системный администратор?) и работает напрямую с разработкой (а кто этим занимался раньше?).

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

Что мешает текущему персоналу освоить этот инструментарий - для меня загадка.

Давайте сделаем вид, что ничего не было.

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

Собственно, чем был вызван шквал сообщений в канал: я сыграл в “ой, не туда”, занимаясь корректурой последнего поста @SinTeZoiD: https://news.1rj.ru/str/anykeynotes/18

А раз “спалился”, то стоит и поделиться. Впрочем, мне есть что на это сказать.

Я недостаточно стар, чтобы знать, как проходила инженерная деятельность в СССР, но я достаточно давно работаю в сфере ИТ и “повидал некоторое дерьмо”.

То, что Миша называет инженерной культурой, для меня выглядит элементарщиной.
Что значит “сборка от васяна”? Почему писать скрипты на Python, а не Bash считается неким элитаризмом?

Я могу писать свои инфраструктурные обертки на Golang. Код будет гораздо меньше, работать будет шустрее и надежнее, но скажут ли мне “спасибо” за это коллеги? Скорее всего нет, потому что они пишут на Python и Bash, и Golang не знают от слова совсем.

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

Миша может сколько угодно думать про трактор (наивный, думает, что в загнивающем западе все по-другому), и что люди не проталкивают красивые и аккуратные подходы к решению задач, а виноваты во всем эффективные менеджеры.

Нет, Миша, нет проблем с инженерной культурой в индустрии. Есть компетентные и некомпетентные специалисты. Среди некомпетентных есть некомпетентные вынужденно (они еще не умеют, но хотят учиться), и некомпетентные по собственному желанию (они не умеют и не хотят учиться).

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

А падающего толкни.

inb4 нет, это не реклама.

Коллеги, если кто-то ищет работу на удаленке - ScyllaDB ищет людей.

https://www.scylladb.com/career-post/senior-solution-architect/

https://www.scylladb.com/career-post/technical-support-engineer/

За всей информацией стучитесь @dyasny.

Стоило разобраться в Well-Architected Framework на более менее приемлемом уровне, как выяснилось, что существует еще и Cloud Adoption Framework.

И если WAF он про продукты на Амазоне, то CAF про, как подготовить организацию к Амазону.

Мне нечего сказать про Trunk-Based Development.
У меня 3 простых принципа: fit for purpose, KISS и YAGNI.

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

https://arstechnica.com/information-technology/2019/07/feds-former-cloud-worker-hacks-into-capital-one-and-takes-data-for-106-million-people/

Если вкратце:
1. Бывший (?) сотрудник AWS смог получить доступ к IAM роли.
2. Воспользовавшись этой ролью сотрудник получил доступ к S3.
3. Сотрудник радостно поделился об этом со всем миром, был арестован, ну и так далее.

Что говорят медиа: “взломали AWS, слили данные”

Плевать на желтушные заголовки, у меня только один вопрос: каким образом роль для сервиса WAF имела доступ в S3?

На всякий случай напомню, что я пишу цикл статей на тему IAM и как их правильно готовить: https://news.1rj.ru/str/manandthemachine/425

Достаточно иметь здравый смысл, понять принципы IAM, least privilege principle и изучить IAM Policy Conditions, чтобы не сесть в лужу.

Использование Mappings в шаблонах Cloudformation для выбора нужного AMI Id из региона - самое идиотское дело.

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

Для тех, кто, как и я, страдал похожей фигней, Амазон сделал публичный репозиторий параметров с идентификаторами машин Amazon Linux 2 (и насколько я знаю и более ранних версий). Использовать его до неприличия просто:

# Parameter section
ImageId:
  Denoscription: 'Latest Amazon Linux AMI ID'
  Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
  Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'

# Resource Section
WebServerLaunchTemplate:
  Type: AWS::EC2::LaunchTemplate
  Properties:
    LaunchTemplateData:
      InstanceType: !Ref InstanceSize
      UserData: …
      ImageId: !Ref 'ImageId'
      SecurityGroupIds:
        - !Ref 'WebServerSecurityGroup'

Есть ли похожие для других дистрибутивов, я не проверял.
Подводных камней у такого выбора параметров два: не получится запустить стек, если отвалился Parameter Store, и нужно иметь в виду, что новые версии AMI могут быть несовместимы с вашим приложением.

Читаю "Никаких компромиссов" за авторством Криса Восса - отставного специалиста по переговорам из ФБР.

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

Так вот в 1979 основатели проекта Роджер Фишер и Уильям Юри выпустили книгу "Путь к согласию", где описывали новую методику. В этом, не постесняюсь этого слова, труде авторы акцентировали внимание на эмоции - один из недостатков разумных существ.

Один из пунктов гласил: не зацикливайтесь на том, "что" хочет человек, но на том "почему" он этого хочет.

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

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

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

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

https://learnworthy.net/highest-paid-programming-languages-in-2019/

Вы просто посмотрите на эту красоту, которая идет десятой в списке "самых высокооплачиваемых языков программирования во всем мире".

Недавно (буквально вчера, кажется) прогремела история с PHP.CE, с которой случилось кое-что занятное: среди докладчиков не было женщин, а львиная доля участников состояла из белых мужчин.

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

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

Первая связана с HR расследованием в Google, которое инициировали сотрудницы. По их словам существовал большой разрыв в компенсациях для женщин и мужчин, и инициативная группа требовала уравниловки.
Разрыв действительно был, но в пользу женщин и цветных: по итогам расследования вышло, что белые мужчины как раз и недополучают. Подробнее здесь: https://www.nytimes.com/2019/03/04/technology/google-gender-pay-gap.html

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

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

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

Довольно редко разница между компенсацией М и Ж вызвана сексистскими наклонностями работодателя.

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

В случае с Ж все проще - достаточно выбить себе 32 часовую рабочую неделю и ЗП, достаточную на удовлетворение потребностей пропустить стаканчик с подруженьками в пятницу вечером.
Расходы на жизнь либо на М, либо на родителях (в зависимости от возраста). Ежели Ж съехала от родителей и снимает жилье, то чаще всего с подружками (что превращает 1500 евро в 500 - вполне подъемная сумма даже с зарплатой в 2000).

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

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

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

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

Четвертая и финальная глава про IAM: https://medium.com/@thomas.storm/aws-iam-deep-dive-chapter-4-policy-evaluation-logic-permission-boundaries-identity-federation-5bbdcf726d74?sk=ba675ac167b1468423f2d9120b84ccdf

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

По сути имеется определенный лагерь элитариев. Снобов, переживших многое в своей карьере, повстречавших всякое, и теперь - чопорных боевых мужиков (и не только), которые смеются в лицо новичкам и их "смешным" проблемам.
В принципе, можно бесконечно копаться в психологической стороне вопроса. Связаны ли снобизм, чопорность, шовинизм, you name it с тем, что большинство очень крутых специалистов пожертвовали личной жизнью для обретения своей экспертизы? Может они интроверты? Может дело в больших (сравнивая с другими сферами) зарплатах? Кадровом голоде? Или детские травмы? А может потому, что в былые времена они пережили схожее и теперь считают, что это - единственный путь к самосовершенствованию (через продолжительное поедание членов в групповых чатах, ага)? Или давайте ударим по гендеру и решим что дело в "токсичной маскулинности", которое, словно рак, поедает индустрию и не пускает в нее барышень, геев, миноритариев и прочих "нежных" персон?

Впрочем, это все бессмысленные тонкости. Прелесть в том, что люди любят прикрывать свои неудачи и проблемы в работе (и не только) той самой "токсичностью", не имея при этом для нее точного определения.

Для кого-то это подколки на работе по поводу прически/одежды/образа. Для кого-то - пассивно агрессивные комментарии во время code review.

В итоге получаем в довесок обратную картину: обиженные, оскорбленные и угнетенные создают свои кружки по интересам, где хвалятся своим Code of Conduct и игнорируют отсутствие полезного и качественного контента (какой там может быть полезный контент, если все эксперты - токсичные снобы, и им в тусовочку нельзя?).

Получается два стула: на одном - синеволосые новички с их странными правилами приличия, на другом - "шовинистичные мудаки", с которыми никто не хочет иметь дело, хотя есть, чему поучиться.

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

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

Я же надеюсь, что вы сделаете правильные выводы из прочитанного.

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

И я это прекрасно понимаю и испытал на своей шкуре. Терпения доносить людям простые истины (которые ты воспринимаешь как "мыть руки перед едой") зачастую не хватает.
Мне нравится подход в @AWS_Ru - если человек пришел с элементарным (на взгляд местных старичков) вопросом, ему просто кидают ссылку на нужную документацию. Если человек начинает неистовствовать - его методично успокаивают и приглашают ознакомиться с оной документацией.

Впрочем, в виду ряда вещей, которым я свидетельствовал (от драмы вокруг Tarantool, выборки Medium до нескольких личных поражений), я постепенно теряю верю в будущее индустрии. Ну вы просто вдумайтесь - разработчики экосистемы Scala ведут срачи на политические темы в твиттере (я так понял, конфликт между Alt-Right’ами и “прогрессивными” ребятами), и из-за этого в сообществе происходит не пойми что.

Я прекрасно понимаю снобов и нередко замечаю снобизм со своей стороны. Даже если иметь бездонную чашу терпения, в какой-то момент просто плюешь на все и понимаешь, что весь образовательный контент (сужу по статистике прочтений постов про IAM на Medium) либо неинтересен, либо люди недостаточно мотивированы (ленивы?) его потреблять.

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

А падающего, как известно, толкнуть сам Заратустра велел.