Человек и машина

2021-11-21 11:44:47 #люди

Джеф Безос однажды сказал: "Хорошие намерения не работают, вам нужны хорошие механизмы чтобы что-то произошло."

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

Один из вопросов, на который мне, после одного инцидента, пришлось ответить: "Что можно было сделать, чтобы избежать этого инцидента?" Я честно ответил, что мне не хватило того и этого, да и в принципе, потрать я больше времени и проверь все раз десять, то не накосячил бы так... за что получил нагоняй от наставника.

Результатом пост-мортема являются одна или более задачи, результатами которых должны быть артефакты:
• Не смог понять, что именно упало - нужны понятные логи и метрики, дашборды и инструменты observability
• Отказ одной системы вызвал цепную реакцию и retry storm - circuit breaker
• Получил уведомление, но не знал что делать - нужны понятные runbook'и и механизмы эскалации

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

И если так подумать, то все инструменты, которые любезно делает ваша группа DevExp (если она у вас есть, конечно): кодогенерация, IDL, герметичная сборка, монорепы и т.д. - это не только ускоряет работу кожаного мешка, сидящего на неприемлемо большой зарплате, но и уменьшает вероятность аварии категории PEBCAC. Открыть/Комментировать

2021-11-14 14:03:48 #люди

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

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

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

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

Со стороны кандидата, чтобы получить желанный оффер из FAANG+, достаточно скрепить зубы и сесть на от 1 до 6 месяцев за LeetCode и просить более опытных товарищей побыть наставниками по архитектуре и проектированию систем.

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

Однако, мне не дает покоя пункт про толерантность к интроверсии кандидатов. Пресловутый Software Engineering отличается от Coding’а именно тем, что за последние десятки лет эта работа социализировалась, и про это хорошо рассказывается в первой главе Software Engineering at Google. Времена атомарных единиц, выполняющих свой кусок задач и ни с кем не коммуницирующих хотя бы в формате текста, канули в лету.

Это вовсе не значит, что социопату закрыт путь в профессию - заходи фрилансером на рынок да бери себе единичные и сложные задачи. Ну или напиши свой Flappy Bird или Minecraft. Но в любой крупной компании придется работать с людьми, и если человек впадает в панику на интервью, то откуда гарантия, что он не впадет в панику на работе? Открыть/Комментировать

2021-11-11 00:51:12 Открыть/Комментировать

2021-11-08 13:43:43 #анонсы

Я обещал, что на этом канале нет и не будет рекламы, но я не расчитывал, что удар в спину реклама придет от самого Телеграмма.

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

Ни от кого. Открыть/Комментировать

2021-11-08 13:40:37 #машины_aws

Пока я работаю над длиннопостом, два занимательных и одновременно неприятных факта про DynamoDB:

1. DynamoDB TTL - бесплатный server-side способ удаления устаревших данных не предоставляет гарантий удаления в срок истечения! Хуже того то, что объекты с истекшим сроком жизни все еще отображаются в запросах, что перекладывает ответственность за фильтрацию валидных данных на клиента. Не смотря на то, что в среднем удаление занимает до 48 часов, мне известны случаи о задержке аж на 10 суток.

2. Capacity Units распределяются по шардам (Partition Key) таблиц, что может привести к ProvisionedThroughputExceededException при том, что throttle происходит только на конкретном шарде - так называемая проблема Hot Partition. По результатам общения с техподдержкой выяснилось, что:
- В режиме provisioned CUs, они равномерно распределяются по шардам; далее DDB будет распределять CU на более активные шарды. Как происходит распределение, когда количество шардов превышает количество CU, неизвестно.
- В режиме OnDemand, каждый шард получает 1000 WCU и 3000 RCU сразу же и перераспределения между шардами уже не происходит, поскольку 1000 записей и 3000 чтений в секунду - верхний порог.

Казалось бы мелочи, но эти мелочи выпили мне немало крови в Uber. И заметно сузили мой личный список подходящих бизнес задач для DynamoDB. Открыть/Комментировать

2021-10-16 11:30:42 #пятничное

Я тут читаю небольшие куски кода на Haskell, и ощущение такое, словно я читаю язык программирования, написанный на нидерландском. Открыть/Комментировать

2021-10-13 16:49:55 #машины_aws

Дубовый евангелизм хуже чем его отсутствие. Вот @count0_digest зачем-то просит объясниться (или оправдаться?) за каких-то чуваков, которые глупейшим образом решили набрать себе трафика и продать свой продукт.

Беглый гугл говорит о том, что Ottertune автотюнит облачные базы. Балдеж, зумеры придумали Oracle AWR/ADDM с красивым UI.

Оставлю продукт в покое, но проедусь по сантименту поста. Во-первых, ультимативные посты в духе You are doing XXX - низкий ход и чистой воды кликбейт. Во-вторых, считать чужие деньги и уж тем более расписывать, на что они тратятся, еще ниже. Не похер ли, на что тратит свое состояние Безос? Вы еще расследуйте, что это за дворец в Гелленджике.

Теперь к посту. Если убрать весь скучный флер, то можно обнаружить следующие советы:
1. Не использовать слишком большие машины
2. Не использовать настройки по-умолчанию
3. Не использовать слишком много PIOPS

То есть те же базовые вещи, которые рассказывают на курсе подготовки к AWS Certified Solutions Architect. Потрясающе! Хорошее повтори и еще раз повтори.

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

Я не хочу ковырять цифры по всему калькулятору, так что посчитаю только один экземпляр m5.8xlarge. По оценке ребят, такая дура c 32 (!!!) ядрами стоит 25к в год. Много, согласен. Только если купить резервацию на год с полной оплатой вперед, цена сразу срезается до 15к. Сумма 25 000 - цена по модели OnDemand которую используют либо по незнанию, либо недолго.

Не говоря уже о том, что правильно выбирать сервер СУБД по разным характеристикам, а ребята-тюнеры взяли сервер “общего назначения” и издеваются над ним как могут.

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

От себя замечу, что лучшая ACID СУБД в AWS это Aurora, и я искренне не понимаю людей, которые заходят в облако и покупают там OpenSource. А потом еще несут деньги всяким хулиганам, чтобы их базы “оптимизировали”. Открыть/Комментировать

2021-10-06 12:00:53 #машины_разное Что случилось с сеткой Facebook без диванных экспертов, конспирологии и спекуляций. Открыть/Комментировать

2021-10-06 11:45:16 #машины_разное

Что случилось с сеткой Facebook без диванных экспертов, конспирологии и спекуляций. Открыть/Комментировать