В 2024 году мы рассказывали, как поднять свой сервер внутри РФ, чтобы получить доступ к российским сайтам из-за рубежа. Проблема остаётся актуальной и в 2026 году. Всё больше сервисов применяют географические ограничения доступа, из-за чего пользователи за рубежом не могут на них попасть. При этом многие граждане РФ живут и работают за пределами страны, но продолжают пользоваться российскими онлайн-сервисами.
Уже несколько лет Диасофт занимается разработкой продуктов в микросервисной архитектуре. На начальном этапе у компании не было потребности в полной автоматизации для организации выпуска, тестирования и доставки на целевые стенды. Со всеми этими активностями справлялись сами команды в ручном режиме с применением частично автоматизации, где это было целесообразно.
Однако со временем в компании была создана экосистема low-code разработки микросервисных программных продуктов Digital Q, которая позволила нашим производственным командам автоматически генерировать часть прикладного кода, что значительно ускорило разработку продуктов.
Как следствие внедрения экосистемы low-code платформ быстро росло количество продуктов и команд. В день мы делали уже более 2 000 коммитов от 100+ команд в 300+ микросервисах на 200+ проектах.
На этом этапе встал вопрос: как теперь быстро, полностью автоматически, выпускать и доставлять все это? Ответом стало решение «Диасофт» Digital Q.DevOps. Оно автоматизирует весь процесс (от сборки и выпуска продуктов до доставки на нужные стенды), включая такие важные этапы, как прохождение автотестов и проверки на уязвимости.
Каждый из вас хоть раз ловил себя на мысли: «А почему бы не начать слушать книги вместо того, чтобы их читать?». Пока едешь в метро, стоишь в пробке, занимаешься домашней рутиной или вместо приевшейся музыки в спортзале — сценариев масса.
В сети полно литературы, но если вы эстет и ищете что-то глубже «Онегина» или модных бестселлеров, то наверняка сталкивались с проблемой: нужной книжки в аудио просто не существует.
Так вот, тут мы попадаем в ловушку. Технологий синтеза речи (TTS) сейчас море, а вменяемого инструмента, чтобы массово превращать текст в звук, нет.
Либо вы платите корпорациям за каждый символ через официальные API, превращая чтение в дорогую привычку, либо ковыряете софт, застрявший в эпохе Windows XP, который озвучивает файлы дольше, чем вы бы читали их вслух сами.
Я системный администратор. Моя работа — заставлять системы работать эффективно, и я не люблю ждать. Не люблю, когда мой домашний компьютер превращается в жужжащую печку, показывая 1% прогресса в час. Этот материал — не просто туториал, а технический разбор и своего рода «дневник» процесса разработки проекта «Прометей». Мы посмотрим, как превратить выделенный сервер в промышленную фабрику аудиокниг, способную выдавать 20 часов готового звука за 11 минут.
Эта статья дополнение к недавнему переводу другой статьи: Как добавить каталог в PATH.
Несмотря на то, что способы, описанные там рабочие, они несут за собой неочевидные трудности.
Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.
Существует несколько различных протоколов, предназначенных для обеспечения бесперебойной работы сети на канальном уровне. Сегодня мы рассмотрим Ethernet Ring Protection Switching – технологию, обеспечивающую высокую доступность и отказоустойчивость в кольцевых топологиях.
Привет, Хабр! Меня зовут Никита Чубаров. По трудовому договору я инженер-эксперт по разработке и сопровождению сервисов, а по факту DevOps-инженер с фокусом на доставку в платформенных командах, которые поставляют общие решения для десятка дочерних команд. Со временем эта доставка перестала быть прозрачной и предсказуемой, и всё больше напоминала космолёт, в котором пилот перед каждым запуском вручную подключает провода, проверяет давление в контурах и по списку нажимает десятки кнопок. Пока запусков мало, это ещё можно представить, но когда их становится сотни, а кораблей — десятки, такая схема быстро превращается в источник ошибок и выгорания.
Примерно в таком состоянии у нас находился Bootstrap Namespaces. В статье я расскажу, как мы прошли путь от сложной CI-оркестрации к декларативному управлению Bootstrap Namespaces через Argo CD и GitOps, какие проблемы это позволило убрать и какие новые ограничения пришлось принять.
Продолжаю серию статей про полезные инструменты для сисадминов. Сегодня расскажу про зарубежные сайты, которые точно должны быть в вашем шорт-листе. Читайте под катом и делитесь своими онлайн-сервисами по мониторингу, тестированию и оптимизации.
В этой статье мы продолжаем разбирать возможности веб‑сервера Angie по борьбе с DoS (и немного DDoS) атаками. В предыдущей части мы разобрали стандартные средства, а в этой обсудим возможности сторонних модулей и системы Fail2Ban.
Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Исходя из моего опыта, могу сказать, что большинство обладателей OpenWrt-роутеров используют для настройки беспроводных интерфейсов достаточно удобный веб-интерфейс LuCI. И только продвинутые пользователи рискуют править конфиги вручную. Но, как правило, даже они часто ограничиваются лишь указанием основных данных: типа стандарта, канала и, собственно, настроек самой Wi-Fi сети. И совершенно зря, так как wireless-конфиг имеет множество самых разнообразных параметров, позволяющих при правильном использовании увеличить покрытие сети или скорость в несколько раз. В этой статье разберем точную настройку файла /etc/config/wireless в OpenWrt, направленную на создание максимально стабильного покрытия Wi-Fi сети. И посмотрим на предрассудки, которые сложились относительно некоторых параметров. Особенно подчеркну, что мы не будем разбирать все параметры (их действительно очень много), а ограничимся только обозначенной задачей.
Привет, Хабр.
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен» — системы учета и контроля ИТ-инфраструктуры. В этой статье хочу разобрать одну из самых устойчивых и при этом недооцененных проблем корпоративных ИТ — несанкционированную установку программного обеспечения, Shadow IT.
Во многих компаниях такие установки до сих пор воспринимаются как частный вопрос дисциплины: кто-то поставил лишнее, кто-то обошел регламент. На практике это не отдельные инциденты, а системное явление, которое напрямую влияет и на безопасность, и на управляемость инфраструктуры.
По нашим наблюдениям, в значительной части организаций сотрудники самостоятельно устанавливают рабочий софт, не проходящий централизованное согласование. Причем речь идет не только о специализированных инструментах, но и о вполне привычных вещах: офисных приложениях, утилитах для обмена файлами, удаленного доступа, аналитики и совместной работы.
Важно понимать: в большинстве случаев здесь нет злого умысла. Причины почти всегда лежат в устройстве процессов. Бизнес развивается быстрее, чем ИТ-регламенты, и людям нужно решать задачи здесь и сейчас. При этом согласование нового ПО может занимать дни или недели. Отдельный фактор — работа с подрядчиками, которые устанавливают их в инфраструктуре заказчика привычные им инструменты.
Еще один распространенный сценарий — передача техники между подразделениями. Устройство меняет владельца, а установленное ранее ПО остается без пересмотра. В результате в инфраструктуре постепенно накапливается слой неучтенного и неавторизованного программного обеспечения.
Последнее время вся моя работа связана с энтерпрайзом и бигтехом. Но так было не всегда. Лет 12-15 назад работал в производственной компании, и там довелось создать «на коленке» систему мониторинга для промышленного оборудования.
У компании были современные импортные станки с проприетарным софтом, дорогим обслуживанием. Непрерывное круглосуточное производство. Но собственная IT-инфраструктура была слаба – всего несколько разработчиков, а аналитики бизнесовые. Всё же бизнесу нужно было следить за оборудованием: кто работает, кто простаивает, кто отключает датчики. Крайне необходимо было снизить вероятность поломок и простаивания.
В статье расскажу, как «на коленке» собрали многомодульную систему.
На почти каждой Linux-машине в мире живёт один маленький бинарник. Весит несколько мегабайт, несколько десятков тысяч строк кода, поставляется со своим собственным конфигурационным языком, и CVE-шек за ним накопилось столько, что хватит на хорошую таблицу с фильтрами. Большинство из нас запускает его по десятку раз в день, не задумываясь.
Этот бинарник — sudo.
В мире Docker-контейнеров, эфемерных CI-раннеров и Kubernetes-подов, которые живут тридцать секунд и умирают без предупреждения, большая часть того, что умеет sudo, попросту не нужна для той работы, ради которой мы его вообще вызываем.
Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.
Монолит без тестов.
Деплой только ночью.
Пять минут гарантированного простоя на каждом релизе.
Логи — в файле.
О проблемах узнаём от клиента.
Малый/средний бизнес МФО, без отдельного DevOps-инженера.
“Специально обученный тимлид”, который знает, какие костыли подпирают систему.
Рассказываю, как из этого получился production baseline: Kubernetes, GitLab CI/CD и наблюдаемость, после которых релизы стали скучными.
Три года назад я написал статью “Интернет-цензура и обход блокировок: не время расслабляться”. Перечитывая ее сейчас, спустя три года, не могу избавиться от двоякого чувства: с одной стороны я почти во всем оказался прав касательно того, как будут развиваться события, усиливаться блокировки, и регулироваться законодательство. С другой стороны, кое в чем я тогда серьезно ошибся.
А именно: слишком уж я надеялся на то, что доблестные фильтраторы интернета будут заботиться об уменьшении побочных эффектов и так называемого collateral damage, и поэтому будут вынуждены изобретать более сложные технологии детектирования, продолжая увлекательную игру в кошки-мышки. Реальность же оказалась гораздо прозаичнее: зачем думать, когда в руке кувалда? В результате чего имеем следующее: часть детектирования откровенно тупая (например, блок нескольких параллельных подключений к одному IP, что решается использованием gRPC-транспорта для VLESS или XHTTP-транспорта с правильными настройками мультиплексирования), а часть - еще тупее, а именно, никакого детектирования, а тупо бан популярных хостеров и облачных провайдеров целыми подсетями /16 и даже /8 - в результате чего или нельзя подключиться по TLS вообще, или можно, но соединение фризится после передачи примерно 16 килобайт данных, или же блок срабатывает на целую подсеть после случайного обращения к какому-нибудь “плохому” IP-адресу. За анализ огромное спасибо товарищу @0ka и его статьям “РКН создали белый список для 72 AS, но пострадали 391 AS (>225 млн IP адресов)” и “РКН создали список подозрительных айпи адресов (динамическая блокировка 47 AS)”.
Хостинговые компании России устранили старые проблемы. Большинство хостингов стабильно держат соединения с крупными интернет-провайдерами (BGP-сессии с аплинками) и правильно объявляют свои IP-адреса в глобальной сети (route-объекты). Клиенты получают сервис высокого уровня без лагов.
Однако все эти достижения могут в один момент разлететься на кусочки.
Когда почта ложится — ложится всё. Переписка, задачи, согласования, доступы — всё завязано на почтовый сервер. А если под ним единственный PostgreSQL без резервирования, то между вами и катастрофой — один сбойный диск или зависший процесс.
В этой статье — пошаговый рецепт: собираем отказоустойчивый кластер PostgreSQL на базе Patroni, используем etcd для консенсуса и HAProxy как единую точку входа. Три виртуальные машины — и ваша почта RuPost переживёт падение ноды без потери писем и без ручного вмешательства.
Продление договора — через три месяца, но поставщик знает уже сейчас, что вы никуда не уйдете. Это и есть vendor lock-in — зависимость от вендора. С ней сталкиваются гораздо чаще, чем принято думать.
Конечно, ITAM-специалисты могут заранее заметить надвигающуюся проблему: у них на руках данные по активам и договорам с поставщиками, статистика использования и календарь продлений. Проблема в том, что зависимость от вендора изначально чаще всего не воспринимается как риск — до того момента, когда уже поздно что-либо менять. Когда риск стал очевиден, простая процедура закупки ПО на замену текущему превращается в крупный проект, который требует отдельного бюджета, ресурсов и многоэтапного плана миграции.
Это руководство поможет выявить, разложить по полочкам и взять под контроль зависимость от вендора — до того, как она начнет управлять вашим бюджетом.
Трудно представить современный компьютер или смартфон без тысяч файлов, хранящих в себе различную информацию. Иногда возникает необходимость что-то найти в этом многообразии, причем критерии для поиска могут быть совсем не тривиальными.
В качестве одного из возможных инструментов для поиска может применяться утилита grep. Grep (сокращение от global/regular expression/print) является одним из самых мощных и часто используемых инструментов в арсенале системного администратора и разработчика. На первый взгляд, её задача проста — найти строки в тексте, соответствующие шаблону. Например, вхождение какого-либо слова в текстовом файле Однако истинная мощь grep раскрывается при использовании регулярных выражений (regex).
В этой статье мы разберём три основных типа регулярных выражений, используемых в экосистеме grep: Basic (BRE), Extended (ERE) и Perl-compatible (PCRE) и рассмотрим несколько практических примеров.
Всем привет! Меня зовут Эрик, я инженер технической поддержки в Ринго.
Если вы администрируете Mac в корпоративной среде, то рано или поздно сталкиваетесь с загадочными сущностями: Secure Token, Bootstrap Token, volume owner, OIK, KEK, VEK.
Проблема в том, что официальная документация Apple описывает их корректно, но сухо и редко объясняет, как всё это связано между собой на практике. В итоге админ узнаёт о Secure Token не из документации, а когда:
— пользователь не появляется на экране FileVault,
— MDM не может включить FileVault или выполнить Erase All Content,
— обновление macOS требует «volume owner»,
— а Recovery внезапно никого не пускает менять настройки загрузки.
Постараемся разобраться поэтапно, что такое Secure Token, что лежит внутри, как он связан с Bootstrap Token и при чем тут MDM.
Статья подготовлена на основе документации Apple, включая Apple Platform Security, доклада Арека Дрейера на конференции MacSysAdmin и ряда дополнительных источников.