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

2021-08-11 15:39:11 #люди

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

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

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

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

Отказывать же нужно аргументированно и аккуратно - глобус маленький, и никогда не знаешь, с кем придется иметь дела в будущем. Лучший способ - честно и прозрачно объяснить почему вы готовы за что-то браться. Мне иногда помогает How to say No, чтобы найти нужные слова, но усложнять нет необходимости.

Нет времени, и вы загружены? Так и говорите.
Не работаете бесплатно? Ничего плохого в этом нет.
Не интересуетесь темой? Явно укажите и перечислите то, что вам реально интересно (авось, подкинут что покруче).
Просто задолбались, выгорели и едете кукухой? Со всеми бывает.

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

2021-08-02 10:51:33 #машины_разное #люди

Пару слов об архитектурных решениях.

Для начала давайте определимся с терминологией:
ADR - реестр архитектурных решений, то есть архив всех архитектурных и дизайн документов с историей.
RFC - request for comments, он же (русское значение мне больше по душе) рабочее предложение - документ, описывающий новое решение или радикальное изменение текущего.

Многие из вас слышали про RFC под разными номерами, и ассоциируете этот акроним только с сетевыми штучками. Это в корне неверно (RFC есть даже по UTF-8 и SQL), и в то же время верно - ведь его придумали не абы кто, а отцы-основатели интернета IETF.

Несложно догадаться, что ADR хранит в себе один и более RFC, как принятых, так и (что еще важнее) непринятых - быть им наукой для новичков, которые с полпинка хотят внедрить вундервафлю и получить солидный бонус.

А что касается RFC, то порядок и формат оформления, рассмотрение и принятие оного разнится от организации к организации. Однако некоторые постулаты неизменны.

Во-первых, RFC обладают своими уровнями: какие-то преподносят изменения, пусть и радикальные, в одно-два места, другие же трансформируют инженерные процессы или организацию в целом. Для сравнения: 1) развернуть один из продуктов на облачном провайдере или 2) перенести все нагрузки в K8s. Идея 1 по масштабу значительно меньше Идеи 2, а значит и рассматривать ее будет меньше людей (об этом позже).

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

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

Ну и самое интересное: после принятия решения - то есть когда RFC подписано всеми, кем надо, и готово к имплементации - оспаривать его уже нельзя. Можно изменить что-то на уровне ниже, но если вы договорились тащить K8s, на полпути переходить на Nomad не выйдет.

Даже если очень хочется. Открыть/Комментировать

2021-07-22 11:58:16 #машины_разное #люди

Недавно на просторах тележки я вступил в одну минидискуссию о проблемах эксплуатации DynamoDB там, где можно было эксплуатировать реляционную БД. Оставим тему за скобками, к этому посту она не имеет отношения.

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

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

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

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

Чтобы этому новичку-карьеристу было проще это сделать, а вам, как автору оригинальной системы, не стыдно, заводятся Записи Архитектурных Решений (ADR). В некоторых местах используются старые добрые RFC.

Кстати, дайте знать, если тема архитектурных решений интересная, могу рассказать подробнее.

Другое дело, когда нужно решать задачи ПЛАНЕТАРНОГО МАСШТАБА. Впрочем, это тема для другого разговора. Открыть/Комментировать

2021-07-17 13:31:10 #жиза

Есть две одержимости, которые я не пойму, да и не приму:
• Одержимость механическими клавиатурами
• Одержимость когнитивной эффективностью вне работы

Причем с механическими клавиатурами все более менее понятно. Раз уж айтишники теперь ремесленники, то и молоток должен быть подходящий. Вопросов больше к пострадавшим от профдеформации настолько, что хотят решать бытовые задачи за O(logn).

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

Я могу понять, когда это делает в силу лени - к примеру, когда люди делают автоплатеж той же коммуналки, а под конец года сводят дебет с кредитом и корректируют сумму.

Но чего я не могу понять, так это бессмысленной, на мой взгляд, экономии умственных сил. Ну то есть, что произойдет, если 5 минут потратить на выбор блюда на завтрак или одежды? Мозг лопнет? "Таски" не закроются?

Стоит ли настолько скупиться мозгом для себя, чтобы отдать его с концами на работу? Зачем копировать повадки Джобса и Цукерберга?

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

2021-07-13 11:17:57 #машины_aws

На той неделе AWS выкатил интересное, но спорное по полезности обновление.

Правила Security Group обзавелись собственными идентификаторами, а значит стали де факто отдельными ресурсами. Базово о практическом применении можно прочитать здесь.

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

Однако есть жирный минус - правила, пусть и со своими идентификаторами, все еще не живут без самой SG и заводить их отдельно нельзя. А бонус от изменения, описанный в примере выше, применим к тем, кто по какой-то причине управляет своей инфраструктурой только через Bash и awscli.

Как будто хотя бы одна маломальски серьезная организация так делает.

К сожалению, новая “фича” выглядит сыроватой, а анонс словно сделан в спешке. Тем не менее, если правила смогут стать полноценным независимыми сущностями и попадут в RAM, то просторов для использования много. Открыть/Комментировать

2021-07-02 18:40:41 #машины_разное

Навеянная историей грандиозного рефакторинга Lingualeo (поищите в сети, если не застали), интересная находка.

Интересна она в том числе и тем, что найти ее оказалось не так-то и просто. Не удивлюсь, если Гугл плохо индексирует запросы о продуктах, написанных на Haskell.

P.S. Для веб-хипстеров есть и GraphQL-версия. Открыть/Комментировать

2021-06-21 13:36:09 #люди

Говорят, на этом докладе можно увидеть авторов @anykeynotes и @manandthemachine. Открыть/Комментировать

2021-06-17 09:15:01 #машины_aws

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

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

Отправить бекап диска виртуальной машины или базы данных - задача частая и вполне стандартная. И шифровать эти самые бекапы тоже идея не из глупых. Шифрование делается с помощью мастер-ключей конкретного аккаунта - Customer Master Key или CMK.

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

1. Делаем нешифрованный бекап
2. Копируем в другой регион
3. Шифруем

Дела были еще хуже, если бекап автоматически шифровался:

1. Дешифруем шифрованный бекап
2. Копируем
3. Шифруем!

Стоит ли добавить, что помимо потраченного времени на дешифрование/шифрование, каждый поход в KMS за ключом стоит денег и отражается в счете?

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

Впрочем, у AWS'а 1000 и 1 способ от таких историй защищаться. Открыть/Комментировать

2021-06-08 14:02:01 #машины_разное

Прекрасный повод в очередной раз поделиться одним из моих любимых докладов. Открыть/Комментировать

2021-06-08 13:37:20 Спорим, это снова Cloudflare?

UPD: Ан нет, на этот раз возможно Fastly. Открыть/Комментировать