#пятничное

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

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

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

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

Так вот, если я могу попросить Алексу или Алису включить мне песню, поискать что-то в сети, рассказать про погоду на улице или как варить этот ваш булгур, то рано или поздно я смогу просить ее записать меня в МФЦ или поликлинику, ну или создать запрос в ГосУслугах.

Шо тут жсон, шо там жсон, делов-то.

Да и в самом МФЦ можно поставить колонку, которая будет отвечать на специфические вопросы, не отвлекая кожаных мешком от важных дел.

А потом я увидел ЭТО.

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

Возможно, прогресс однажды дойдет, но даже Ариса из “Лучше чем люди” звучит противоестественно (респект Паулине Андреевой), чем заставляет подсознательно отторгать ее.

Причем, ОК,согласен - поставить колонки с Алисой в МФЦ беспонтово (или украдут). Но можно же было сделать няшного робота со смешной шарообразной головой, которые ровно так же отвечал бы на животрепещущие вопросы? Зачем вызывать у людей, которые до сих пор прорабатывают с терапевтом страх перед логотипом ВИD, еще большую панику? Не понимаю.

#машины_aws

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

Чего только стоит необходимость запускать Shell скрипты из spec-файла. Да, даже если весь скрипт состоит из одной команды.

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

#люди

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

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

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

Однако задница горит только так, в путь. Вот представьте - сидите, долго корпите над ПРОБЛЕМОЙ, продумываете РЕШЕНИЕ, и задумываетесь о применении ИНСТРУМЕНТА. Идете к эксперту, а тот чем рассказать про этот инструмент, вместо этого сам задает встречные вопросы, да и вообще братишка, тут все по новой надо, и вообще не то делаешь. Скотина такая.

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

И не стоит забывать, что обе стороны могут быть правы, да и в конце концов в вопросах архитектуры всегда есть откупы. Так что холиварить нет смысла.

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

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

#машины_aws

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

Казалось бы, в AWS работают очень умные люди - и это не шутка - но от некоторых моментов волосы встают дыбом. Да, я снова о семействе Code*, на этот раз о CodeBuild.

Итак, гениальный момент №1: сборки выполняются из под root. Нет смысла объяснять почему это плохо, но к счастью в buildspec есть инструкция run-as, как для всей сборки, так и для конкретных шагов. Однако, откуда нам знать, под каким пользователем надо выполнять сборку если не под рутом? Такой пользователь есть, но его не найти в документации. Я нашел его на SO, и вот где он спрятан.

Гениальный момент №2: как вы догадались, у этого пользователя прописывается путь к домашней директории, но самой домашней директории у него нет! Прибавьте к этому пляски с доступом к ФС, а также сборку Maven’ом, и получается полный антигуманизм. Решается созданием нужной директории и присваиванием этих прав нужному пользователю.

Итоговый файл спецификации выглядит вот так:

version: 0.2
run-as: codebuild-user

phases:
install:
run-as: root
runtime-versions:
java: corretto8
commands:
- mkdir /home/codebuild-user
- aws s3 cp s3://b/settings.xml ~codebuild-user/.m2/settings.xml
- chown -R codebuild-user:codebuild-user ~codebuild-user

build:
commands:
- mvn build # …

Другой вариант: создание собственного образа.

Customer obsession’ом отдает за версту, поддержку уведомил.

#машины_aws

И раз у меня Пятница Горящих Жоп, я не могу пройти мимо этой прекрасно выверенной дезинформации.

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

Два момента:
1. Хваленый IMDSv2 защищает от подобного вектора атаки приблизительно никак. Достаточно сначала запросить токен, потом с этим токеном сходить в мету.
2. Кто вообще наделяет виртуалку в облаке правами администратора облака?

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

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

Зачем? Ну затем, что у меня очень много AWS credit’ов. И еще больше свободного времени.

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

Самостоятельные лабы:
1. Amazon EKS Workshop - хорошая мощная лаба по EKS с дополнительными внешними инструментами. Подойдет для тех, кто уже прикинул k8s к носу и хочет вертеть его на AWS. Не понравилось, что завязана на eksctl, но там партнерский материал, ничего не поделаешь.
2. https://container.training/kube-selfpaced.yml.html - 2232 слайда почему-то отбили желание копать дальше оглавления, но кишки и обертки рассматриваются, что уже хорошо. В конце, что важно, рассказывается как обновлять кластеры (я слышал, обновление куба вызывает паническую атаку даже у самых опытных YAML-разработчиков).
3. https://github.com/kelseyhightower/kubernetes-the-hard-way - лаба от отца-основателя. Хороша тем, что ступень за ступенью, плоха тем, что ориентирована на GCP, впрочем чего еще ожидать.

Курсы:
1. https://kodekloud.com/courses/certified-kubernetes-administrator-cka/ - собственно то, что я сейчас прохожу. Аналогии с кораблями и капитанами мне не заходят (говори со мной на моем языке, камон), но кишки рассказываются очень хорошо.
2. Курс от Слерм - я его не слушал, но слышал много хорошего про Слерм.

Экзамены я сдавать не собираюсь, поэтому мне нерелевантно, но если вдруг:
1. https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/
2. https://killer.sh/

Книги (ни одну не читал):
- https://www.amazon.com/Managing-Kubernetes-Operating-Clusters-World/dp/149203391X - посоветовали под постом, по оглавлению выглядит глубоко.
- https://www.amazon.com/Advanced-Platform-Development-Kubernetes-Management/dp/1484256107 - нашел сам, похоже на то, что я хочу делать с кубиком, т.е. не сколько поднять его, сколько поднять внутри него нужную инфраструктуру.
- https://www.packtpub.com/product/mastering-kubernetes-third-edition/9781839211256 - нашел сам, как опубликовавшийся автор Packt, я знаю, что книги серии Mastering лучшее, что может быть по теме, и эта книга не исключение (чего стоит покрытие федерации и кросс-региональных кластеров).

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

Ну и надо будет ковыряться в этом новом инструментарии. По поводу чего еще одна просьба - напишите в комментариях, что вы используете с кубом? Почему не взяли альтернативы?
Например: ArgoCD/Flux, CRI-O/containerd, istio/linkerd, calico/cilium?

Холивары допускаются, оскорбления друг друга нет.

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

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

Всех деталей не раскрою, но если вы используете Nitro экземпляры ЕС2 в AWS, т.е. 5-ое поколение M и C типов, убедитесь, что в clocksource у вас kvm-clock. Сэкономите себе нервов.

https://www.brendangregg.com/blog/2021-09-26/the-speed-of-time.html

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

И еще немного о времени, уж очень у меня подгорело.

1. Привет, перевод часов.
2. Привет, еще один список заблуждений.

Когда там уже Meta сделает нормальное железо для времени?

#машины_aws

Я продолжаю издеваться на Code* сервисами… Хотя скорее они надо мной.

В этой части разбираюсь с поведением CodeDeploy в Blue/Green развертываниях, а так же с тем, что не умеет CodePipeline и CDK.

Ваше прокрастинационное чтиво.

#пятничное

(прочистил голос)

6. Отмена НДС на покупку золота.

Голос нидерландов:

1. Тикток ушел из России
2. Макдак закрылся
3. Старбакс закрылся
4. Кока кола уходит
5. Наворованное чиновниками национализируют в бюджет

Если б я не знал контекст, я бы подумал, что Россия не просто встала с колен, а аж подпрыгнула

(ну сначала немного подпрыгнула. прим. ред.)

#машины_aws

Моя эпопея с семейством Code* практически подошла к концу. Это был довольно интересный проект, которым я надеюсь однажды поделиться с амазонщиками либо на митапе, либо на конфе, там уж как Uber разрешит.

Добивающим фактором стала особенность поведения CodeDeploy при сине-зеленом развертывании с копированием AutoScaling Group (почитайте пост с Медиума, я там подробно по этому прохожусь). ASG, с которыми я работаю, привязаны к двум Target Group'ам Application Load Balancer'а. После релиза, я обнаружил, что новая ASG ни с одной TG не ассоциирована.

Оказалось, что это баг CodeDeploy - если группа привязана к одной TG, то все будет работать как надо. А вот если две, то ни одна цепляться не будет. CodeDeploy не поддерживает одновременно две TG на одну Deployment Group.

Решилась проблема с помощью скрипта, который в фазе AfterAllowTraffic делал работу, с которой CodeDeploy справляться был не в состоянии.

Решение подглядел у своих коллег по этой ссылке.

Теперь составляю список противных вещей в DevTools от AWS, который однажды туда отправлю. Вот, что собрал:
• Поддержка нескольких TG в CodeDeploy Deployment Group
• Ссылки в логе CodeBuild обладают подчеркиванием, но не кликабельны (привет, UX)
• Поддержка override параметров в CodePipeline во время запуска, например, разово взять исходники из другой ветки репозитория в стадии Source.

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

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

А все заметили, что Jira прилегла? Эта новость особенно неприятно смотрится совместно с другой, а именно end of support self-hosted версий продукции Atlassian.

Понять решение Atlassian можно - сопровождать зоопарк из разных версий (многие, особенно толстые, заказчики не спешат с обновлением), железа, ОС и СУБД невероятный труд, не говоря уже о том, что масштабируется с трудом. Так что консолидация продаваемого продукта на мощностях самого поставщика осмысленна и прозрачна.

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

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

P.S. Могли бы просто конский ценник за сопровождение Atlassian Server выкатить, да и все. Теперь будем неделю слушать улюлюкание, что ваши клавды фуфло.

P.P.S. Инфраструктурщикам Atlassian сил и терпения, долгоживущие инциденты, пожалуй, самое мерзкое, что может произойти с дежурным.

#жиза #пятничное

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

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

Без лишней дотошности могу сказать, что ближайшим ко мне определением наставничества является оное из абсолютно упоротого фильма “Замысел”:

Х: Над всеми стоят Наставники. Они создадут проблему и наставят на путь ее преодоления. Передадут самые ценные знания, ничего не требуя взамен.
(спустя сцену)
У: Там были грабли.
Х: Угу, это я их подложил.
У: Но мне же больно!
Х: Ты получил шишку на лоб и опыт за плечи. Шишка пройдет, а опыт останется. Задача наставника не рассказать как избежать беды, а наставит на ее преодоление.

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

P.S. А фильм посмотрите, он крутой.

#машины_aws

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

Если это сообщение наберет 500 🔥, я расскажу вам адовую историю о том, как недокументированное поведение CodeDeploy после успешного развертывания привело к уничтожению нашего промышленного кластера и отказу систем и как я потом добивался от техподдержки здравого смысла.

Обещаю лонгрид на русском (Хабр) и английском (Медиум) с краткой выжимкой тут.

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

Брендан Грегг покинул Netflix. Мы пока не знаем, куда именно, но одно известно: он продолжит работать с клавдиями, что безусловно подливает интриги в котел спекуляций.

За время работы в Sun, Грегг покричав на серверы, разработал DTrace, его опыт в Netflix подарил нам Systems Performance, flame graph'ы, много интересного контента и BPF Performance Tools.

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

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

Яндекс открыл исходный код YDB, став на моей памяти первой именитой технической компанией, открывшей код своей системы хранения данных.

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

UPD1: В комментариях напомнили про Clickhouse, так что Яндекс сделал это дважды.

UPD2: Tarantool был раньше. :]

#машины_aws

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

Самое “приятное”: я за всю карьеру не написал столько пост-мортемов и не провел столько разборов инцидентов, сколько за год в Uber. Добавлю это в свой список сомнительных поводов для гордости.

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

Само собой, это легко звучит на бумаге и едва ли реализуемо на практике. Так что пока пинаю ТАМов, эскалирую куда могу и стою над душой.

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

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

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

Брендан Грегг таки не разочаровал и теперь будет работать в Intel.

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

Это отличное решение для Intel в первую очередь. Надеюсь, экспертиза Грегга поможет конторе занять конкурирущющие позиции с многочисленными ARM производителями.

#машины_aws

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

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

Вынужден признать, что из-за таких приключений лучшие умы Большого Теха ™ с недоверием относятся к managed service’ам облачных провайдеров.

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

Группа черных шапок, известная в определенных кругах как NB65, некоторое время назад сообщила о взломе защищенного периметра Qiwi и утечке платежных данных.

Об этом написали несколько Телеграмм каналов (например), после чего шум быстро поутих. По моей информации из Qiwi ничего не утекало, сами Paysystem Tech какой-либо связи с Qiwi не имеют (сайт у них какой-то мутный вдобавок, они живы вообще?).

Если у вас есть другая информация, поделитесь со мной в ЛС или в комментариях.

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

А все потому что по правилам PCI-DSS, хранение CVV кодов даже в системе токенизации запрещено. :) Утекший номер и дедлайн карточки все еще является критической информацией, он попадает под PCI и PII (персональные) данные, но простому хитрозадому болванчику с ними ничего особо не сделать.

Учитывая вышесказанное, неудивительно, что потуги хакеров не получили никакой реакции, кроме общественной ;)

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