Человек и машина
1.81K subscribers
46 photos
1 video
2 files
346 links
Авторский блог Карена Товмасяна.
Идеи, слова поддержки и критики отправляйте мне - @ThomasStorm.

С предложениями рекламы не обращайтесь.

I do not speak on behalf of my employer.
Download Telegram
#машины_разное

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

Оно и правильно - раз обещал рассказать про внешнюю консистентность, будь добр сдержать обещание!

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

Understanding External Consistency

Ставим лайки, делимся материалом, подписываемся, жалуемся в комментариях “а почему не на русском?!”!
#машины_aws

1. У Facebook инцидент с сетью
2. Facebook заводит партнерство с AWS
3. https://aws.amazon.com/message/12721/
#машины_aws

Чем дилетанты отличаются от неудачников:
- Дилетанты осознают свои возможности и учатся
- Неудачники улюлюкают и устраивают клоунаду в Твиттере

Очевидно, дилетантам надо помогать и наставлять, а неудачников гнать и насмехаться.

Понедельничное чтиво для моих любимых дилетантов : мой набор трюков, как не тратить лишних денег на AWS.
#машины_разное #люди

Многим знакома такая практика как Code Freeze - блокировка изменений на период рождественских/новогодних праздников, чтобы не усложнять жизнь дежурным. Окно обычно занимает около двух недель или более, в зависимости от страны, а его строгость зависит от домена, в котором оперирует бизнес.

И не смотря на общепринятость практики, находятся те, кто с ней не согласен.
Роберт Росс, СЕО FireHydrant и выходец из Digital Ocean, призывает перестать это делать.

Я не разделяю мнение автора, но в его словах есть рациональное зерно: заморозка не предотвращает, а отодвигает неизбежный инцидент.
#машины_разное

Site Reliability Engineering я прочитал несколько раз с перерывом в год с лишним. Подобное “перепрочтение” позволяет еще раз по мере роста опыта взглянуть на ту или иную задачу.

По схожей причине сейчас перечитываю SRE Workbook, а конкретно главу Alerting on SLOs. От того интереснее еще раз пройтись по термину burn rate.

Полностью все описывать нет смысла, прочитайте по ссылке, там очень интересно, даже если вы далеки от SRE практик.

Подход SLO и error budget привносит в работу операций нотку экономики. И именно таким образом авторы из Google предлагают реагировать на нездоровость системы.

Возьмем SLO по успешным ответам (2ХХ) 99.9%. Иными словами, только 0.1% запросов или 1 из 1000 не будут корректно обработаны системой. SLO растягивается на часы, дни, кварталы, месяцы и так до года. Каким образом выбрать временнОе окно для замеров и логику уведомлений?

В Google решили применить способ расчета под названием Burn Rate - в каком темпе “съедается” наш заделанный на год бюджет ошибок, в искомой главе есть небходимые значения. Расчет самого burn rate я не понял, если кто понял, напишите в комментариях, обучите уму разуму, мне под конец года уже лень.

А поскольку “гореть” можно слабо, но продолжительно, а можно ярко, но недолго, умные ребята предложили интересную математику: возьмем несколько окон, несколько burn rate’ов, Булеву Алгебру и получим удобные и своевременные уведомления, на которые можно реагировать.

Наглая копия из книги:
expr: (
job:slo_errors_per_request:ratio_rate1h{job=“myjob”} > (14.4*0.001)
and
job:slo_errors_per_request:ratio_rate5m{job=“myjob”} > (14.4*0.001)
)
or
(
job:slo_errors_per_request:ratio_rate6h{job=“myjob”} > (6*0.001)
and
job:slo_errors_per_request:ratio_rate30m{job=“myjob”} > (6*0.001)
)
severity: page


Итого ловим судорожные звонки от робота, когда система сбоит жестко в течение пяти минут И часа ИЛИ чуть помягче в течение получаса И 6 часов.

Сложно, да. А вы как хотели?
#машины_aws

Распространённый миф о безопасных клавдиях больно ударил, что по Capital One в 2019 что по Twitch в 2021.

Непопулярное мнение: все эти инциденты - вина владельцев и инженеров сервисов и инфраструктуры и только их.

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

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

Читаем, применяем, не даем злодеям и своим наделать глупостей.

Всех с наступающим! Увидимся в 2022.
Старая добрая традиция!

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

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

Планы, как всегда, грандиозные. Исполнены, как всегда, будут не все. :)))

С наступающим!
#машины_aws

(голосом радиоведущего) Мы прерываем наш отпуск, чтобы поделиться важной информацией!

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

Исследователи из Orca Security нашли брешь в AWS CloudFormation, позволящую выполнять вызовы на стороне сервера, получая доступ к любому аккаунту AWS. Ранее уязвимость с похожими возможностями была найдена в сервисе Glue (ETL процессинг), на данный момент уязвимости в обоих сервисах устранены.

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

Всех с прошедшими праздниками!

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

Я дал интервью изданию Highload, где рассказываю о том чем занимался до того, как завел канал, и как изменилась моя жизни после. Кому интересно, милости прошу: часть первая, вторая и третья.

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

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

Если бы не она, меня бы тут с вами не было, а мой успех в том числе результат ее, иногда прямых, действий.
#машины_разное

В ядре Linux есть интересный системный вызов mmap (memory map) , “привязывающий” указатель на файловый дескриптор к пространству имен внутри процесса.

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

В виду удобства использования, mmap иногда использовуют в качестве прослойки между storage engine у СУБД и операционной системой. Работа с файлами и хранилищем - довольно скучный и неблагодарный труд, так что неудивительно, что ее пытаются отдать на откуп операционной системе.

Однако mmap откровенно не подходит для СУБД (передаю привет MongoDB). Он не обеспечивает изоляцию и атомарность транзакций, поскольку файл может быть записан на диск самой ОС в любой момент и это не поддается контролю, но обходится с помощью Copy-on-Write. mmap может так же считать файл из кеша, что по сути дублирует один и тот же файл в памяти дважды.

Исследователи из университета Карнеги-Меллона (в очередной раз) провели исследование о совместимости mmap и СУБД, (в очередной раз) придя к выводу, что смешивать их не стоит. Стоит использовать O_DIRECT и писать свой собственный buffer cache/pool.

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

Дамы и господа, я сдаюсь и нуждаюсь в вашей помощи.

Пора изучать k8s по серьезке. Как учат куб те, кому за 30 кто уже разбирается в оркестрации контейнеров?

git clone https://github.com/kubernetes/kubernetes.git
уже предлагали.
Человек и машина
#машины_разное Дамы и господа, я сдаюсь и нуждаюсь в вашей помощи. Пора изучать k8s по серьезке. Как учат куб те, кому за 30 кто уже разбирается в оркестрации контейнеров? git clone https://github.com/kubernetes/kubernetes.git уже предлагали.
Подборка получилась космическая, спасибо всем участникам!

По совету @yangand сделаю шортлист с комментариями. А пока пойду по серт. курсам, ибо так в свое время прокачался в AWS, с чего бы про проторенной дорожке снова не пройти?

По комментариям делаю вывод, что сложность не в самом кубе, а в разнообразии инструментов, которые вокруг него городят, и отсутствие стандартов и общепринятых практик. Штош, Well-Architected не только к AWS применим.
#пятничное

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

Ожидаемо и объяснимо, что механические действия будут автоматизированы, от работы на производстве до обслуживания клиентов общепита. Пользы тут как минимум две: 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?

Холивары допускаются, оскорбления друг друга нет.
👍1
#машины_aws #машины_разное

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

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

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