В Испашке подход к личным сертификатам совершенно дырявый. Собственно аналог паролей на бумажке прилепленной к монитору.

PKI здорового человека:

— PKCS#11 токен генерит ключевую пару и приватный ключ никому не показывает, достается из токена только послойным спиливанием и осаждением электродов.

— CSR с публичным ключом передается в CA

— CA выдает сертификат

— Далее этот токен является личным и ни он сам ни пин от него не передается третьим лицам

PKI курильщика:

— сайт CA генерит .pfx файл

— этот файл скачивается и вместе с паролем передается бухгалтерам, ведущим отчетность владельца сертификата

— бухгалтера требуют указать стандартный пароль

— сами эти .pfx файлы я подозреваю хранятся где попало: в почте, на шарах в офисе, передаются по телеге, лежат на телефонах и т д

Ну то есть привет non-repudiation. И это мы ещё опускаем что, например, налоговая не умеет работать с контрактами, подписанными электронно, хотя формально должна.

Причем эта дырявость не точечная а общепринятая: 2 бухгалтерские компании и 2 CA работают по одинаковой схеме.

Я тут упорно продолжаю есть кактус, используя сабж в конфигурации Rootless Docker over HTTPS. Использовать можно одним способом — убив все процессы на клиенте и запустив с нуля. Поскольку HTTPS соединение Gateway к докеру со временем отпадает.

Ну и периодически возникает баг — если качать обновления IDE со скоростью меньше примерно 20 мбит/сек, он не укладывается в 10-минутный таймаут и обрывает скачивание на полпути.

И сегодня я нашел путь не заниматься этой ерундой с выкачиванием. Если стоит хоть какая-то версия IDE (в докере) — то эту IDE прописываете в /.jbdevcontainer/config/JetBrains/host-config.json (привет FHS, они реально папочку в корне создают) и настает вам счастье. Аналогично при обновлениях или удалении старой версии через Manage Backends.

Ещё можно терминал закрепить как таб редактора. Но тогда перестает работать Ctrl-E и этот терминал иногда самозакрывается, прибивая все запущенные из него процессы, я ещё не понял при каких обстоятельствах.

Я тут уже битый месяц делаю сабж. Сделал ему отдельную репу, и там папочки business, ops, dev и projects. И внутри projects/{foo,bar,baz}/ то же самое business-ops-dev. А внутри маркдаун-файлики типа 01-overview.md

"Номера глав" болван предложил, оказалось удобно. Разбиение на business-ops-dev вышло из моего опыта с Archimate и исходя из того, что с LLM будут общаться люди с разными ролями (которые у нас уже есть).

У нас есть значительное количество бизнес-стейкхолдеров. Это и наш внутренний C-level, и С-level клиентов. Что вот эти люди, которые в технику не лезут, должны знать о компании и системе? Все идет в business/

Далее у нас есть народ, который в технику лезет, но не лезет в код что-то там править. Когда они будут общаться с LLM, им надо знать про логи-метрики-админки, саппорт, диагностику проблем, стектрейсы, деплоймент, конфигурирование системы. В-общем довольно много.

Ну и наконец, собственно разрабы, которые постоянно видят код.

business/01-portfolio-and-product-status.md

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

business/02-team.md

Тут персоналии. И наши работники, и внешние стейкхолдеры. Кто есть кто, по каким каналам коммуницируем, общие концепции управлениt командой (совещания, дисциплина).

business/03-business-meeting-format.mdОдной из задач будущей системы автоматизации является автоматизация совещаний, которые у нас бизнес- и технические. Вот для бизнес-совещаний тут оговаривается их формат и в каком виде нам нужен будет отчет. Пока несколько сумбурно.

Глобальные папки dev и ops пока ещё более сумбурные — там то что болван наизучал из общих принципов дизайна систем в ходе работы. Типа того что в DynamoDB мы не используем монотаблиц.

В проектах интереснее.

Я тут пытаюсь внедрять у себя AI coding, вот некоторые соображения.

0. Убедитесь, что вы не ИИ-ебанат. Реальность такова, что очень много народу не знают как готовить этот ваш ИИ. Врубайтесь в prompt engineering и context engineering, изучайте сильные и слабые стороны моделей, консультируйтесь в не-ебанатами, делайте как они.

0а. Начинайте с простого. Это так часто является проблемой, что стоит упомянуть отдельно. Ебанаты представляют себе такого «силлогического мудреца на горе» и дают ему абсурдные по сложности задачи, после чего захлопывают ноут в сердцах. Представьте что перед вами 10-летний сын начальника, который якобы силен в компьютерах. Дайте ему пузырек, и если справится — усложняйте.

1. Инет завален всяким говном. На этапе пилотного проекта вам говно не нужно, вам нужен state of the art.

1а. Не занимайтесь онанизмом, который был уместен пару лет назад. Берите инструменты, которые будут лазить по сорцам и логам, коммитить, пушить, и даже ждать зеленого CI за вас. State of the art агентские системы, с такими же моделями, с таким же контекстом и промптами.

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

Собственно шансов на то что вы сможете нанять 3 смены круглосуточных админов, которые дадут вам 3 девятки, за сумму меньшую, чем 2к — нету совершенно.

И поэтому мы платим эти 2к AWS.

Если измерять в дедиках на хетцнере то это много. А если измерять в трехдевяточных SRE командах — то мало. Ну и там за эти деньги не только надежность, но ещё и например безопасность.