Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM
Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.
Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.
При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.
Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.
Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов
Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.
Внутри:
Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов
Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок
Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM
Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах
Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI
Обходит большинство самых мощных и популярных капч:
reCAPTCHA v2 и v3;
Cloudflare Turnstile;
FunCaptcha (Arkose Labs);
GeeTest и GeeTest v4;
Amazon WAF;
KeyCaptcha;
Grid, ClickCaptcha, Rotate, Canvas;
обычные текстовые и графические капчи, в том числе аудио.
Библиотека небольшая, работает стабильно, разработчики её поддерживают, добавляя новые виды капч. Можно настраивать таймауты решения капч, чтобы имитировать поведение человека.
Как оптимизировать бюджет Service Desk на 2,9–10 млн. руб. в год и повысить опыт пользователей
По данным Forrester, 60-70% сотрудников пишут в Service Desk напрямую, минуя портал самообслуживания. За годы инвестиций в каталоги услуг, базы знаний и формы типовых запросов цифра не сдвинулась. Это не проблема UX, а системный сбой модели: портал требует, чтобы пользователь думал на языке поставщика услуг.
В новом аналитическом обзореАндрея Вишнякова – директора по бизнес-продуктам SimpleOne, ITIL 4 Master, ITIL 3 Expert, автора методологии РИТМ –разобрали, почему классические подходы упираются в один и тот же потолок, как ИИ-помощник на RAG превращает концепцию Shift-Left из давней идеи в работающую практику, и сколько это стоит в рублях – с расчётом экономии для трёх типичных объёмов обращений и опорой на данные Forrester и Gartner.
что именно компании делают, когда хотят «починить портал»: редизайн каталога услуг, обучение пользователей, расширение первой линии, скриптовые чат-боты – и где ломается каждая из четырёх стратегий;
цена неэффективности – кто и сколько теряет: от простоев сотрудников до перегрузки экспертов второй линии;
как устроен ИИ-помощник на RAG-архитектуре: векторные коллекции, требования к базе знаний, условия внедрения, сценарии применения – от ИТ-инцидентов до HR-справок и заявок в АХО;
финансовая модель для трёх типичных объёмов (30, 70 и 130 тыс. обращений в год) с потенциальной экономией от 2,9 до 10 млн ₽/год.
Как я связал Zabbix и таск-трекер в обе стороны без отдельного сервиса У меня боевой Zabbix 7.0 на ~260 хостов, а заявки дежурной смены живут в Planfix. Уведомления в Telegram или Matrix никто не отменял, но когда над инцидентами работает смена, мессенджер неудобен: не видно, кто взял проблему, нет статусов и истории по задаче, сложно готовить отчеты. Хотелось, чтобы проблема мониторинга сама заводила задачу в трекере, а действия с задачей возвращались обратно в Zabbix, и всё это без сервиса-прослойки.
Очевидные пути отмёл сразу:
Бот или демон - ещё один процесс, который сам надо мониторить: новая точка отказа в системе, которая как раз следит за отказами.
Почта с парсером - не возвращает id созданной задачи обратно в Zabbix, и потом нечем связать восстановление триггера с конкретной строкой в трекере.
Требование «вернуть id задачи на событие» и определило всю архитектуру.
Прямое направление: Zabbix → трекер Собрал на штатном media type типа Webhook: один JS-скрипт по флагам события решает, какой эндпоинт трекера дёрнуть. Интереснее, где хранить связь «проблема ↔ задача». Внешнюю БД соответствий заводить не стал, обошёлся тегами события. При создании задачи скрипт возвращает Zabbix теги __zbx_planfix_taskid и __zbx_planfix_link; при process_tags=1 они вешаются на событие, и все последующие операции (подтверждение, закрытие, отмена) находят ту же задачу по тегу. Состояние живёт прямо на событии, отдельное хранилище не нужно.
Что всплыло уже в бою: отмена эскалации Уведомление «Escalation canceled» (эскалацию погасили, отключив хост или триггер) приходит с теми же флагами, что и новая проблема: event_value=1, event_update_status=0. Не различишь - скрипт примет отмену за новую проблему, заведёт дубль, и задача зависнет открытой навсегда: OK-события не будет, закрывать нечем. Поэтому скрипт сначала ищет в тексте уведомления фразу «Escalation canceled» и, только если её нет, считает событие новой проблемой. Подтверждение и снятие различаю по макросу {EVENT.UPDATE.ACTION}: в первой строке update-сообщения он разворачивается в acknowledged или unacknowledged - по этому слову задача уходит «в работу» или возвращается исполнителю по умолчанию.
Обратное направление - и оно оказалось самым интересным Делается средствами самого трекера, без отдельного сервиса. В Planfix это автоматический сценарий: событие «задача принята», условие «проект = ZABBIX», операция - POST в JSON-RPC API Zabbix, метод event.acknowledge с action=6 (подтвердить + добавить комментарий). Event ID берётся из поля задачи, того самого, что прилетел при создании. Главное: обратный вызов несёт email сотрудника, и подтверждение с комментарием проставляются в Zabbix от имени этого человека, а не безликого сервисного аккаунта. В истории события видно, кто реально взял проблему - тот, на кого назначена задача в трекере.
Что ещё пришлось учесть
maxsessions=1 обязателен, иначе закрытие может обогнать создание, и правка придёт по ещё не существующей задаче.
Создание задачи не идемпотентно: при ретраях возможен дубль (из Zabbix не узнать, дошёл ли запрос на самом деле), поэтому дедуп по event_id на стороне трекера обязателен - у меня он пока в планах.
Шумовой фильтр - через эскалацию: операция на шаге 2 плюс условие «подтверждено = нет», иначе проблемы, мигающие по 30 секунд, плодят задачи.
Итог: ноль дополнительных демонов, обе системы синхронны, связь хранится на самом событии. Для одной пары систем это окупается. Но чем больше разных систем хочется соединить между собой, тем громче вопрос об оркестраторе: точечные вебхуки перестают масштабироваться, хотя единая шина и есть та самая прослойка, которую потом сам обслуживаешь. Сейчас как раз думаю в эту сторону. Чем вы сшиваете зоопарк систем - оркестратором или точечными интеграциями, и где у вас прошла граница?
Git reset: как управлять историей и не уничтожить свою работу
git reset — одна из тех команд, которые удобно держать под рукой, но страшно запускать без понимания последствий. Она помогает очистить локальную историю, убрать лишние коммиты, отменить git add или полностью откатиться к нужному состоянию. Но в режиме --hard может стереть незакоммиченные изменения так, будто ничего и не было.
В новой статье разобрали, что делает git reset, чем отличаются режимы --soft, --mixed и --hard, когда команду можно использовать безопасно, а когда лучше выбрать git revert или git restore. Отдельно показали типичные сценарии: объединение нескольких коммитов, вывод файлов из индекса, полный откат и восстановление после неудачного reset --hard через reflog.
Представлен открытый учебный проект 100 free open-source github repos everyone needs - 100 бесплатных репозиториев для решения любых задач. У них полностью открытый код и актуальные инструменты:
ИИ-агенты и скиллы для них;
Локальные альтернативы SaaS-сервисам;
Фреймворки и плагины для любых задач;
Топовые тулзы для разработчиков;
Курсы и справочники по всевозможным темам;
Дизайн и фронтенд-разработка;
Извлечение данных и аналитика;
Безопасность и приватность в сети;
Сборник инструментов для подготовки контента.
При этом у каждого проекта своя лицензия, а авторы подробно разбирают их назначение и способы применения.
GitHub Actions не маскирует секреты из фоновых процессов
Настраивал CI, в котором токен доступа переполучается в фоне — раз в 30 минут, пока идут тесты. Первый токен замаскирован через ::add-mask::, но что с экранированием новых токенов в логах? Можно ли вызвать ::add-mask:: прямо из фонового процесса?
В документации GitHub я ответа не нашёл. Там есть только общее место: workflow commands вида ::... раннер читает из stdout шага. А вот что происходит со stdout, который остался от фонового процесса после завершения шага, — непонятно.
Решил проверить — сделал тестовую репу. Схема простая: в одном шаге запускаю background-процесс, который через 15 секунд пишет ::add-mask:: — уже во время следующего шага. Потом специально печатаю секрет: сразу, после sleep, в следующем шаге и в отдельном job’е.
Foreground-секрет (маска из основного процесса) — замаскирован во всех шагах той же job’ы ✅ Background-секрет (маска из фонового процесса) — открыт везде, и до, и после срабатывания ::add-mask:: ❌
Бонус: маски вообще не живут между job’ами — даже foreground-маска в зависимом job’е уже не действует ❌
У нас это, к счастью, не стреляет: переполучение токена уходит в /dev/null, тесты ходят через API, секрет в stdout не попадает. А вот если какой-нибудь refresh-скрипт всё-таки может напечатать новый секрет в лог — на ::add-mask:: из background-процесса рассчитывать нельзя.
Дисклеймер: и код, и текст этого поста написаны в соавторстве с Claude Code.
Россию отключают от привычных серверов синхронизации времени и DNS-сервисов. Проверьте свои SMTP-настройки, вторичные DNS и прочее - возможно, они уже не работают.
Открытый проект OptimizerDuck позволяет очистить Windows 10/11 от мусора и бесполезных процессов (телеметрию, рекламу, Copilot, все фоновые сервисы и ненужные приложения):
оптимизирует ПК для работы и игр, настраивает GPU и производительность процессора, работает с менеджером автозагрузки, удаляет встроенный bloatware, чистит систему.
может откатить все изменения, если в процессе что‑то пошло не так. Бэкап у вас точно будет.
работает без установки, без ограничений и полностью локально.
Обновил вчера Ubuntu 25.10 на 26.04. В последние два года я обновляю Ubuntu при каждом новом выпуске, начиная с 23.10 насколько помню. И никаких проблем ни во время обновления, ни после него до этого не возникало. Вчера же столкнулся с несколькими неприятностями:
Объём загружаемых пакетов вырос с обычных 2 Гб до 4 Гб! Вероятно у вас будет меньше, ведь это зависит от установленных вами пакетов, но если судить относительно прежнего объёма, то скачёк потребления трафика с учётом мобильного доступа не радует. Скаченные пакеты я сохранил, чтобы на других ноутбуках с Ubuntu не пришлось снова качать 4 Гб. Раньше я так не делал.
Во время установки пакетов рабочий стол заблокировался с сообщением, что у меня нет прав root, чтобы что-то сделать, что именно не написано. Причём нажатие на Отмена блокировку не снимало, и окно сообщения оставалось открытым. Похоже на какой-то баг Gnome, Resolute или где-то глубже в системе. Дождался, когда индикатор диска и вентилятор успокоятся, в надежде, что обновление закончилось успешно, переключился на консоль и сделал reboot.
После первой загрузки и входа в Gnome рабочий стол завис. Снова переключение в консоль и reboot. После второй перезагрузки Gnome заработал. Это ещё один явный баг.
Теперь после каждого включения с нуля или после сна, не важно, запускается какой-то процесс localsearch, который интенсивно работает с диском и греет процессор. Причём процесс ветвится. Как отключить не понятно. Подождав полчаса сделал kill по номеру процесса localsearch. И вынужден делать это каждый раз.
В остальном пока вроде всё нормально. Особых нововведений не заметил. Пиктограммы программ в главном меню стали меньше. В строке статуса появился значёк режима нагрузки процессора.
В предыдущих выпусках был ещё баг с thumbnailer, который при открытии в Nautilus папки с большим количеством фото, выжирал остатки памяти, что приводило к торможению всей системы намертво и последующего принудительного жёсткого отключения питания (известный баг Linux, который за десять или более лет так и не исправлен). Как я понял, в 26.04 thumbnailer был заменён на что-то другое, и я пока ещё не поимел проблем с большими папками с фото. Но посмотрим…
UPD Посмотрел, что это за localsearch. Похоже, что это часть Gnome. Поэтому стандартными средствами управления сервисами его не отключить. Запускается при входе в Gnome. Как эту ненужную мне и вредную с точки зрения энергопотребления и шумозагряднения штуку выключить в Gnome? (В комментарии дали совет, но в первый раз нужно всё-таки сделать kill для процесса, одного его отключения не достаточно. После перезагрузки процесс localsearch уже не будет беспокоить.)
Резюме Ещё до обновления я начал искать альтернативы Ubuntu, понимая что запросы системы к процессору и памяти растут, Ubuntu всё больше походит на bloatware и corporate, а переходить на более новое железо я не собираюсь. Пока в качестве альтернатив рассматриваю: antiX, Devuan, Gentoo, Void, Guix, NetBSD, OpenBSD. Этот набор обусловлен тем, что мне нужно, чтобы система поддерживала 32-разрядность. И я хочу иметь на 32- и 64-разрядных системах одинаковый опыт и навыки работы с ними. А какие альтернативы Ubuntu используете вы? Что скажете про мой список альтернатив? Кстати, до полного перехода на Ubuntu я также работал в последние годы с ElementaryOS, Manjaro, Fedora. Пробовал antiX, Void, NixOS и Guix. По большому счёту они отвергнуты были в том числе по тем же причинам, что теперь и Ubuntu, Кроме antiX, Void и Guix. Это особый случай, и это отдельная тема для разговора.
Что не так с DeFi и почему там до сих пор происходят взломы
Со стороны DeFi выглядит как будущее финансов: кошелёк вместо банка, смарт-контракт вместо посредника, а код вместо правил “по договорённости”.
Но в реальности DeFi это не одно приложение, а связка протоколов, смарт-контрактов, пулов ликвидности, оракулов, мостов, токенов управления и внешних интерфейсов. Пользователь видит кнопку Swap или Deposit, но под капотом может запускаться целая цепочка вызовов между контрактами. И чем больше таких зависимостей, тем больше поверхность атаки.
Одна из главных проблем - composability. В DeFi протоколы часто строятся друг поверх друга: lending-протокол использует один токен, DEX даёт ликвидность, оракул поставляет цену, мост переносит актив между сетями, а поверх всего этого работает ещё один интерфейс. Это удобно для разработки, но опасно для безопасности. Ошибка в одном элементе может стать проблемой для всей цепочки.
Отдельный риск - смарт-контракты. В традиционной системе подозрительную операцию можно остановить, откатить или вручную проверить. В DeFi логика другая: если транзакция валидна и контракт позволяет выполнить действие, сеть его выполнит. Поэтому баг в коде, ошибка в проверке прав, неправильная работа с балансами или уязвимость в математике протокола могут стоить не “небольшого сбоя”, а сразу миллионов долларов.
При этом атаки давно не сводятся к классическому “взлому”. Часто злоумышленник не ломает сервер, а использует экономическую механику протокола. Например, через flash loan можно взять огромный объём ликвидности в рамках одной транзакции, временно исказить цену в пуле, повлиять на расчёт залога или ликвидации, а затем вернуть заём до завершения блока. Формально всё может пройти по правилам контракта, но результат будет разрушительным.
Большая зона риска - оракулы. DeFi-протоколам нужно откуда-то получать цены активов. Если протокол берёт цену из слабого источника, например из тонкого пула с низкой ликвидностью, этой ценой можно манипулировать. Дальше начинается цепочка: неверная цена → неправильная оценка залога → ошибочная ликвидация или вывод средств.
Ещё одна больная точка - кроссчейн-мосты. Мосты соединяют разные сети и часто хранят или контролируют большие объёмы ликвидности. Это делает их идеальной целью. Проблема в том, что мост должен одновременно доверять событиям в одной сети и корректно выпускать или разблокировать активы в другой. Любая ошибка в валидации сообщений, подписях, мультисиге или логике relayer-ов может привести к катастрофе.
Есть и governance-риск. Многие DeFi-протоколы управляются через DAO и governance-токены. На практике это означает, что изменение параметров протокола, обновление контрактов или управление казной может зависеть от голосований, делегатов и концентрации токенов. Если управление плохо защищено, атакующий может повлиять не на код напрямую, а на правила игры.
Парадокс DeFi в том, что он создавался как trustless-система, где не нужно доверять посредникам. Но на практике пользователь всё равно доверяет: аудитам, разработчикам, оракулам, мостам, мультисигам, фронтенду, governance-механике и экономической модели протокола.
То есть доверие не исчезло. Оно просто переехало из банка в инфраструктуру.
Именно поэтому DeFi до сих пор остаётся одновременно самой интересной и самой уязвимой частью крипторынка. Чем больше открытости, автоматизации и связности между протоколами, тем сложнее сделать систему безопасной не только на уровне кода, но и на уровне экономики, ликвидности и пользовательского сценария.
Передача параметров ssh с помощью суффиксов имени хоста
В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).
Host tproxy
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:
изнутри с переадресацией портов,
изнутри без переадресации портов,
снаружи с перадресацией портов,
снаружи без переадресации портов,
для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.
Сущность предлагаемой доработки
Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.
В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:
Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
Hostname srv-10-79.rtk.company.com
Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
ProxyJump gate-10-1+yota
Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:
Match originalhost "tproxy,tproxy+*"
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.
Match originalhost "*+rsa,*+rsa+*"
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
Если вы сидите на MacOS / iOS и у вас VPN на VLESS+XTLS‑Reality, то при очередном обновлении системы/VPN-клиента с высокой вероятностью всё сломается или уже сломалось. Это не баг Shadowrocket и не баг xray-core. Apple ввела квантово-безопасное шифрование TLS 1.3 по умолчанию в iOS 26 / macOS 26, которое увеличивает размер TLS ClientHello на ~1216 байт. REALITY-сервер xray-core не может корректно прочитать такое большое сообщение — отсюда firstLen = 0 и отсутствие соединения. Windows это не затронуто. Простого/универсального решения нет, т.к. откат на предыдущую версию в экосистеме Apple — тот ещё квест. Если ваше клиентское приложение VPN позволяет настроить TLS → Fingerprint, тогда там необходимо выбрать firefox или Crome110 — для которых ещё не было поддержки X25519MLKEM768. В этом случае всё легко чинится.
Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов
Системное администрирование давно не ограничивается «поднять сервер и настроить доступы». Сегодня инфраструктура живёт в контейнерах, кластерах, пайплайнах, распределённых системах и мониторинге, который должен подсказать о проблеме раньше, чем её заметят пользователи.
В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.
4 июня, 20:00. «Продвинутый Bash». Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.
Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс(сейчас всего за символические 10 руб)
Если работаете с контейнерами и Kubernetes
2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux». Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.
1 июня, 20:00. «Мониторинг распределенных систем». На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.
GitOps без романтики: эксплуатация, советы, решения
Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.
В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.
Что на повестке
Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.
Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.
Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.
Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.
Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.
Puppet 8 for DevOps Engineers — книга, после которой лучше понимаешь инструмент
Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.
И книга оказалась просто 10 из 10.
Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.
Что внутри:
Сначала автор рассказывает историю создания Puppet и задачи, ради которых он создавался. Потом переходит к философии: почему он устроен именно так, как работает декларативный подход, зачем нужна идемпотентность и почему это важно для управления инфраструктурой.
Большой блок посвящён коду. Код описан через примеры и советы, но так же описаны типовые ошибки, подводные камни и наследие старых версий, которое всё ещё можно встретить в живых инфраструктурах, но лучше заменить. Не всегда код из книги отрабатывал корректно, нужны были мелкие правки, может это из за версий, а может задумка автора, чтобы ты немного прикладывал голову.
Отдельно понравилось, что есть главы про архитектуру использования Puppet, серверную часть, конфигурирование, тонкую настройку, логирование, мониторинг и эксплуатацию. То есть это не только книга для тех, кто пишет Puppet-код, но и для тех, кто потом будет держать всю эту систему в работоспособном состоянии.
Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.
Так же в этих главах становится понятно что автор не просто пользуется Puppet, а является частью его команды разработки. Отсюда и такой уровень погружения в разные аспекты инструмента.
По итогу:
Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.
Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.
Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.
Почему у Bitcoin несколько типов адресов и в чём их отличие
Большинство пользователей просто копируют Bitcoin-адрес и отправляют средства, не особо задумываясь, почему одни адреса начинаются на 1A1zP1..., другие на 3J98t1..., а третьи выглядят как длинный набор символов вроде bc1qw508....
На практике это не “разные виды биткоина”, а результат эволюции самой сети Bitcoin. Каждый новый формат адресов появлялся как попытка решить конкретные проблемы: высокие комиссии, ограниченную пропускную способность, сложность транзакций или недостаточную эффективность сети.
Самые старые Bitcoin-адреса - это Legacy-адреса. Обычно они начинаются на 1. Это первый массовый формат адресов в сети Bitcoin, который использовался ещё задолго до появления современных обновлений. Главный минус таких адресов сегодня - менее эффективная структура транзакций, из-за чего комиссии обычно выше.
Позже появился формат SegWit. Чаще всего такие адреса начинаются на 3. Его главная задача была довольно практичной: уменьшить размер транзакций и снизить нагрузку на сеть. Благодаря этому комиссии стали ниже, а сама сеть - эффективнее. По сути, SegWit стал одним из самых важных обновлений Bitcoin за последние годы.
Следующий этап - Native SegWit или Bech32. Именно эти адреса начинаются на bc1. Сейчас они считаются более современным вариантом для обычных переводов. Такие адреса занимают меньше места в блоке, ещё сильнее снижают комиссии и лучше подходят для современной инфраструктуры Bitcoin. Именно поэтому всё больше кошельков и сервисов по умолчанию используют формат bc1.
Но эволюция на этом не остановилась. После обновления Taproot в сети появились и новые типы адресов bc1p..., которые уже связаны не только с экономией комиссий, но и с более сложными возможностями сети. Например, Taproot улучшил эффективность multisig-транзакций, частично повысил приватность некоторых сценариев и подготовил основу для более гибких механизмов работы Bitcoin в будущем.
Из-за этого сегодня в сети одновременно существуют сразу несколько форматов адресов. Старые варианты никуда не исчезли, потому что Bitcoin очень осторожно относится к совместимости: сеть должна продолжать работать даже с кошельками и сервисами прошлых поколений.
Именно поэтому один пользователь может отправлять BTC на адрес формата 1A1zP1..., другой на 3J98t1..., а третий на bc1qw508... - и все они всё равно работают внутри одной сети Bitcoin.
Если упростить, разные типы Bitcoin-адресов - это не хаос и не путаница, а следствие того, как сама сеть постепенно развивалась, пытаясь сделать транзакции дешевле, эффективнее и технологически гибче.
