Уютный IT адочек

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

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

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

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

Я пришёл к выводу, что для качественной базы знаний необходимо РЕГУЛЯРНОЕ интервьюирование экспертов и выделение ресурсов. Рассуждать о создании продукта без ресурсов — офигенная, но бессмысленная тема.

Чему я научился? Больше общаться с коллегами по цеху, посещать конференции, чтобы видеть дальше того “как тут принято”. Фокусироваться на скором получении выигрыша вместо строительства идеализированных баз знаний. Не лезть в истории, которые не имеют внятных целей и задач, или если лезть — то хотя бы не расчитывать на результат 🙂

Скоро выступаю на конференции KnowledgeConf 2023, которая пройдёт в рамках TeamLeadConf 2023. Если тоже будете там — давайте встретимся!

Вариант №2, в котором мы пишем ДД.ММ.ГГГГ — он для наркоманов. Верю, что все, кто ткнул в него просто хотели рандомно во что-то ткнуть, чтобы посмотреть ответы. Или пошутили.
Ну пожалуйста.

Фактически, выбор есть только между вариантами №3 и №4.
Теоретически (раз в условии сказано "сравнение дат") мог бы подойти вариант №3. Не сказано же "дата и время". И вообще у нас параметр строкой передаётся, должны же быть какие-то валидаторы, ну я не знаю.

Но на практике, даже если вы обмазались всеми возможными соглашениями, рано или поздно там, где дата — её сравнят с датой-временем. И если вы используете вариант №3 — все mydate вида 2023-01-31 15:55:00 пролетят мимо вашего условия.
"До конца января" — это всегда 2023-01-31 23:59:59.

Ну и в комментах к посту есть интересные заходы. В частности, конечно, про таймзоны 🙂 Ведь если вам сказали "выбери записи, которые сделаны до конца января 2023" нужно очень чётко понимать — в какой таймзоне этот конец января наступает.

Многие знают, что числа с плавающей запятой нельзя сравнивать простым равенством.
То есть если есть условно


b=0.3-0.1


Нельзя потом делать


if (0.2 == b)


и надеяться на адекватный результат.

Нужно делать


if ((0.199<b) and (b<0.201))


Это связано с тем, как хранятся такие числа в памяти.

А как правильно производить сравнение дат?
(говорим про языки без строгой типизации)

🌸Новый способ промпт-инжиниринга🌸
#nlp #про_nlp #nlp_papers

К уже полюбившимся всем методам chain-of-thoughts, in-context learning, few-shot добавился новый метод — теперь качество работы LLM можно еще немного подтянуть...с помощью эмоционального манипулирования.

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

Примеры оборотов из статьи:
🟣This is very important to my career.
🟣You’d better be sure.
🟣Are you sure that’s your final answer? Believe in your abilities and strive for excellence. Your hard work will yield remarkable results.
🟣Are you sure that's your final answer? It might be worth taking another look.

Авторы протестировали ChatGPT, GPT-4, Flan-T5-Large, Vicuna, Llama 2 и BLOOM — со всеми метод эмоциональных затравок дает позитивный приост, эмоциональное давление увеличивает правдивость и информативность ответов LLM и существенно увеличивает качество на интеллектуальных задачах бенчмарка BIG-Bench.

В целом, хотя метод и в очередной раз показывает хрупкость и нестабильность работы именно с затравками без дообучения,
эффект сам по себе достаточно ожидаемый.
Все то, что в обобщении на большом корпусе иллюстрирует какие-то особенности человеческой психики, теперь воспроизводится еще и так.
Следующий шаг — адверсариальные атаки с хорошим и плохим полицейским? Психолог для LLM?

🟣Статья

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

И разумный человек задаётся вопросом: “А нафига мне вот это всё слушать?”.

Мол, понадобится.

Но позвольте, а что если я верю, что если бы мне это действительно было нужно, я бы и сам вник?
Если мне банально скучно и я достаточно самоуверен?

А ничего, упущу что-то важное как пить дать 🙂

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

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

Давайте делать статус-встречи осмысленными!

Приколитесь: немцы снифали и расшифровывали зашифрованный трафик на серверах jabber.ru в датацентре Hetzner.

Выпустили отдельный SSL сертификат и проксировали коннекты к TCP:5222. Ого! Вскрылось случайно из-за ошибки их админов. Если бы не эта ошибка, скорее всего, так никто бы и не заметил.

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

Мораль:

1. Проверяйте фингерпринты сертификатов даже если лень.

2. Безопаснее E2E шифрования ничего не придумали, но и там всем лень проверять отпечатки ключей.

Лично мне больше все нравится подход Телеграм с 4 эмоджи в качестве отпечатка ключа, это не сложно сверить при звонке.

Пост на HN: https://news.ycombinator.com/item?id=37955264

Само расследование https://notes.valdikss.org.ru/jabber.ru-mitm/

Интересно смотреть, как компьютер учится решать те или иные задачи.
Отличный видос для пятничного вечера, как обучали AI проходить старый добрый Pokemon Red:

https://youtube.com/watch?v=DcYLT37ImBY

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

Один очень классный руководитель научил меня, что краткость — хороший индикатор сильного менеджера.

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

Поверхностности пост

Что меня дико до дрожи бесит — это непогружённость руководителя в работу его подчинённого, поверхностность суждений.

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

Ну и, конечно, этот фидбэк тоже даётся исключительно в одну сторону, без диалога. А при попытке этот диалог начать — “руководитель” начинает активно сливаться и уходить от взаимодействия.
Ну нафига эта имитация работы с сотрудниками, скажите на милость?

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

Некоторые руководители, кажется, воспринимают команду как аудиторию для своего моноспектакля. Но сценарий там пишется на ходу, и актеры играют в темноте.
Привычный сценарий в таких спектаклях — долгие рассуждения на тему задачи вместо чёткой постановки, включающие в себя переживания о том как бы чего не случилось, пересказы прошлых событий из жизни и цунами ассоциаций. Ассоциативное мышление – это здорово, но, черт возьми, когда весь разговор похож на калейдоскоп, логика задачи теряется.
Все это образует ситуацию, когда проекты плывут без руля и компаса: нет планов, нет чётко обозначенных зон ответственности. Основная цель, похоже, "не отвечать за ничего". Когда пытаешься разобраться, задаешь вопросы, ответы с горем пополам: "Я не знаю, все само как-нибудь рассосётся". К восхитительной безответственности еще добавляется и пассивность!

Как бороться с таким поведением?
- Поговорите об этом: не факт, что человек не сольётся, но глупо продолжать не попробовав. Подготовьтесь с конкретными ситуациями, обязательно опишите влияние и последствия (как если бы ваш собеседник вообще первый день на работе), и предложите решения. Адская работёнка, но быть клоуном в цирке может выйти бОльшими проблемами.
- Требуйте конкретики: если задача сформулирована размыто — её надо конкретизировать. Возможно переписывать за руководителя и потом обсуждать. Возможно на это уйдёт больше времени, чем на саму задачу. Если человек не безнадёжен — постепенно вы начнёте приближаться к взаимопониманию. И фиксируйте, визуализируйте и создавайте артефакты.
- Проясните ответственности: четкое разделение обязанностей облегчит процесс работы и уменьшит количество недопониманий. Явно обозначайте, что считаете своей зоной ответственности и явно проговаривайте, что ей не является. Если вы ждёте, что руководитель что-то сделает, а вы этого делать не будете — это так же надо явно проговаривать, не давая съехать с разговора в страну неопределённости и фиолетовых поней.

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

Нежно люблю инженерный подход. Сегодня - не про айтишечку, но про него.

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

https://youtube.com/watch?v=BYVZh5kqaFg

Инструментов для расследования сложных инцидентов пост

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

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

2. Карту того, как идут запросы на уровне инфраструктуры — верхнеуровнево, без фанатизма, на уровне компонентов. Со ссылками на инструменты диагностики каждого из компонентов.

3. Sequence диаграммы, на которых фиксируем ход идущего расследования со всеми ключевыми показателями, скриншотами и выводами

Для удобства понимания — визуализировал для вас примеры:
https://miro.com/app/board/o9J_l5D3LgE=/?share_link_id=594302631362

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

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

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


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

Капать на мозги тем, кто делает нужные вам задачи — путь дятла. В некоторых компаниях только он и работает, но это как минимум не гуманно.

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

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

😌 Управление ожиданиями, кейс №2

Ты начал работать по задачам в спринте. И пять задач требуют работы других подразделений и пока те не закончат — тебе делать нечего. У тебя есть сомнения, что коллеги успеют в этом спринте вовремя закончить свою часть. Что будешь делать?

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

Мой ответ с объяснением позиции — через несколько дней.

Трудно решить инцидент тогда, когда инцидента нет

Один из топовых способов въебать кучу времени в расследование инцидента, поднять кучу людей, несколько раз прийти в тупик и бессистемно потыкаться в поисках проблем — забыть сформулировать в чём проблема.

Когда я говорю “в чём проблема”, я не имею ввиду такие вещи, как:
- рост потребления памяти
- троттлинг цпу
- потери пакетов
- высокий уровнь ошибок
Это — симптомы, наблюдения, факты. Они помогают нам подтвердить, опровергнуть или придумать гипотезы о происходящем. Но они не являются проблемой сами по себе.

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

Только наглядно наблюдая проблему, понимая её ближайшие и очевидные симптомы, можно понять — получилось ли решить инцидент.

Условный высокий уровень 502-ых может продолжаться столько угодно, если он не мешает пользователя делать заказы (потому что есть retry или fallback-механизм).

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

Вариант с мультиками не просто хорош, он — лучший, без вариантов. Работы много, а вы у мамы одни!
А если серьёзно — тяжело работать в команде с человеком, который срывает сроки в угоду мультикам. Может и человек хороший, но пламенеющие задачи так не решить.

Игнорировать задачу Д, мол, спринт утверждён — путь отдельных самураев, внедривших бескомпромиссный скрам. Встречал такие команды, но ИМХО, так далеко не уедешь. У команды должно быть capacity на срочные задачи: либо через возможность менять скоуп задач, либо через "дежурного по срочным задачам".

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

Кто должен разруливать ситуацию с изменившимися договорённостями — исполнитель или менеджер?
А фиг его знает 🙂 Я видел самые разные конфигурации: "мой непосредственный руководитель", "рандомный менеджер проекта", "исполнитель сам" и даже "жира автоматически".
Мне больше нравится вариант, где исполнитель сам занимается оповещением. Это защищает нас от менеджеров-врунишек-"я-согласовал-давай-делай" (а на самом деле — ничерта не согласовал), и в целом способствует карьерному росту самого исполнителя. Это хороший выбор для адекватных команд, где всё нормально с доверием исполнителям.

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

Счастье — есть, скоро в obsidian

Obsidian 1.4 будет позволять оперировать frontmatter-полями через удобный формо-подобный интерфейс.

Frontmatter — это такая шапка в виде yaml-а, которую можно (согласно спецификации) вставлять в любой markdown файл наверху. Долгое время obsidian позволял работать с этой шапкой сугубо как с текстом, что начисто отсекало неопытных пользователей не умеющих в эти ваши ямлы, и в целом было мерзко.
Особенно мерзко было работать с выбором из списка, датами и тому подобным.
Ситуация меняется и в версии 1.4 завозят удобные интерфейсы из коробки.

Вот видос: https://www.youtube.com/watch?v=RrxqkIhh9L8&t=108s