Виртуальные мобильные операторы (MVNO) стали привычной частью телеком-рынка. Их запускают банки, ретейлеры и операторы фиксированной связи, превращая мобильные услуги в элемент экосистемы и инструмент удержания клиентов. Однако изначально MVNO создавали для других целей — борьбы с монополией крупных операторов связи. Разберем, как развивалось это направление, и что происходит на рынке сегодня.
Привет! Я — Саша Басун, инженер направления пользовательских ИТ-сервисов в «Петрович-Тех». Сегодня я пришёл к вам с историей о том, как вывод значения ключа из реестра Windows может упростить обработку заявок в отделе технической поддержки.
Если коротко: помощь со стороны нашей техподдержки нередко начиналась с мема «Давайте поможем Даше найти Internet-ID на рабочем столе». Тут нет-нет, да все стадии от гнева до принятия пройти придётся. В итоге после заявки, которая пришла уже мне, родилось маленькое, но изящное решение на C#.
Если у вас российский номер, my.telegram.org с VPN выдаёт ERROR при создании приложения, а без VPN вообще не открывается. Антифрод сверяет страну номера и страну IP - и они не сходятся. Разбираю, почему обход через VPN - тупик, при чём тут DNS, и как получить api_id и api_hash одной строкой в файле hosts за 5 минут, без покупки номеров телефона других стран.
Виртуализация должна была упростить пользовательский опыт в больших и гео‑распределенных компаниях и снять нагрузку с ИТ‑служб. Но на практике оказалось, что перенос рабочего места в дата‑центр решает одни проблемы и одновременно создаёт другие.
Это особенно проявилось на фоне «бума» российского VDI в 2022 году. VDI отлично справляется с офисными приложениями, неплохо живёт с web‑сценариями и требует особого подхода к CAD‑ и мультимедийным нагрузкам. Но самый парадоксальный эффект проявляется в организации видеоконференцсвязи (ВКС).
Разберёмся, почему видеосвязь требует особых подходов к оптимизации, без которых цифровое рабочее место остаётся только наполовину виртуальным, какие есть российские ВКС и что делать их поставщикам, чтобы не ломался UX.
С момента выхода PiKVM в 2017 году рынок IP KVM стал активно развиваться. Я протестировал почти все из этих устройств и готов дать объективную оценку каждому.
Для удалённого управления компьютером из любой точки LAN вы можете использовать инструменты вроде Remote Desktop, Screen Sharing или VNC. И если у вас нет собственной VPN, то полноценный удалённый доступ вам помогут обеспечить RealVNC или Raspberry Pi Connect, либо можете сами настроить сеть через Tailscale или Pangolin. Всё это прекрасные решения, как и SSH, если вам не требуется графический интерфейс.
Но бывают ситуации, когда вы не хотите запускать на ПК программу для удалённого управления. К примеру, когда я удалённо выполняю бенчмарки, мне не нужно, чтобы функция совместного использования экрана отнимала ресурсы системы. Или представьте, что у вас есть компьютер, к которому вам необходимо иметь возможность удалённо подключиться в любой ситуации. В таком сценарии, если этот ПК вдруг зависнет или по какой-то причине отключится, SSH и Screen Sharing уже не помогут.
И здесь на сцену выходит технология IP KVM. В передовые серверные решения она встраивается по умолчанию (к примеру, в HP iLO, Dell iDRAC или IPMI), но не у всех есть доступ к серверным материнским платам. И даже если он есть, BMC (Baseboard Management Controller) может оказаться сильно устаревшим, или же вы можете решить подключиться с использованием установленного GPU, а не встроенной VGA-графики.
Привет! Меня зовут Максим Черотайкин, я инженер 1С в Selectel. Практически каждая компания использует 1С, когда ей нужно автоматизировать учет и бизнес-процессы, а также вовремя сдавать отчетность. Платформу можно запустить на разных операционных системах: Windows, macOS и других. Однако многие специалисты избегают Linux, потому что в нем нет графической оболочки и он кажется сложным для работы. В статье хочу убедить вас, что на самом деле это просто. Для этого мы установим 1С на сервер Linux в облаке своими руками.
И так, вы в Telegram Web и вы запускаете безобидное на первый взгляд Mini App, сворачиваете его или просто переключаетесь на соседний приватный чат, чтобы продолжить переписку. Казалось бы, контексты изолированы, фрейм приложения неактивен, и вы в полной безопасности. Но так ли это на самом деле?
Как превратить крик души в работающую утилиту и попасть в официальную ArchWiki? Мне 17 лет, и мне просто надоело тянуть HDMI-кабель от ноутбука к телевизору через всю комнату. В этой статье я расскажу, как написал свой стример экрана FluxCast на Python, с какими багами Smart TV пришлось столкнуться и как устроен «слепой» дебаг проприетарного железа по логам пользователей со всего мира.
В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.
Работа с rsync и многими другими утилитами для бэкапирования несёт в себе совершенно не очевидную и от этого особенно недооценённую опасность — риск получить рассинхронизацию содержимого файлов, о которой никто и никогда не узнает до того, пока не станет поздно. Статья задумана как рассказ об очень интересной, но малоизвестной утилите precizer. С её помощью можно контролировать целостность данных при синхронизации, бэкапировании или восстановлении файлов. Программа вполне удобно организована и позволяет убедиться, что ни один байт не был утерян в процессе.
Основано на реальных событиях (обожаю этот жанр кино!)
Учитывая просто отвратительную надёжность современных HDD, статья описывает ставшую уже тривиальной борьбу с последствиями выхода HDD из строя.
Материал разделён на несколько глав, пестрящих избыточными техническими подробностями с целью обосновать, почему было принято именно такое решение, а не иное. Возможно, читателям такая архитектура покажется полезной и удобной, и возникнет непреодолимое желание повторить, но сделать ещё лучше! В тексте будет много IMHO, эмоций и попыток плоско пошутить. Гарантирую!
Кому интересен ответ только на главный вопрос, можно сразу перейти к практике использования программы precizer.
Выделенный жирным текст можно читать отдельным слоем и получить краткое представление о затронутых темах.
Антивирусы в Linux, хоть и обитают в основном на серверах, перестали быть диковинкой. И, в отличие от Windows, не сращиваются с операционной системой, а работают как отдельностоящие программы с невысокими привилегиями. Подход со сканированием в «песочнице» напрашивается сам собой. А Qubes OS, наряду с Docker-контейнерами и полновесными виртуальными машинами, подходит для этого очень хорошо.
Пошагово разворачиваем OpenWrt в Proxmox, переносим DHCP и DNS на домашний шлюз, ставим sing-box, подключаем Xray/VLESS Reality и заворачиваем только нужный трафик через туннель.
3 января 2004 года марсоход «Спирит» коснулся поверхности Марса в кратере Гусева. Двадцать один день спустя он перестал отвечать на команды, ушёл в бутлуп и чуть не погиб от своей же операционки. О том, почему инженерам JPL этот инцидент до сих пор снится в кошмарах, как NASA дважды чуть не потеряло марсоходы из-за одной и той же ОС и почему везде важна правильная конфигурация — в статье.
У моего клиента есть пара железных серверов, которые используются для хранения и раздачи статических файлов. Все бы ничего, но любое оборудование требует внимания и регулярного мониторинга. Со временем диски, модули памяти и другие компоненты могут выходить из строя. Причем умирают они не сразу, сначала молча сыплются ошибки в логи, а потом уже поздно что-то предпринимать: даунтайм, kernel panic, fatal error, ретроспектива и панические атаки. Поэтому важно своевременно отслеживать состояние инфраструктуры и реагировать на предупреждения до того, как они перерастут в серьезные инциденты.
По-хорошему раз в месяц кто-то должен садиться и изучать логи на аномалии, если нужно — писать тикеты и ждать завершения технических работ с серверами. Вполне логичная и рабочая схема, в которой сама собой напрашивается автоматизация, комплексный сбор логов, выявление узких мест и уведомления в профильные каналы. Но, как ни крути, нужно оптимизировать процессы и резать косты, да и человек не всегда имеет желание следить за показателями.
Выражение «искусственный интеллект всех заменит» заиграло новыми красками. Нет, от естественного интеллекта я не отказываюсь, но конкретно анализом «здоровья» этих железных серверов теперь занимается локальная ИИшница. Сейчас покажу, что удалось запилить, как я прикрутил локальную модель и написал нишевого агента под нужды клиента, чисто для анализа логов с железных серверов.
Как-то раз в мою сисадминскую жизнь пришел простой и понятный, но, как оказалось, не самый тривиальный запрос - как сделать так, чтобы на WiFi клиентам не нужно было включать ВПН/прокси. Подключился к сети - [Вставьте свой любимый сервис] заработал. Красота. И чтобы надежно было, не отваливалось. И админить удобно.
Основная идея - сделать все на минималках. Без скриптинга, без тяжелого mangle. Чем ближе к голой маршрутизации - тем лучше.
В общем, что у меня получилось, тем и хочу поделиться. В этой статье не будет ничего про аренду и настройку VPS, про обзоры прокси/ВПН технологий и всего такого. Полагаю, что все уже готово и настроено.
Сразу скажу, это не гайд для новичков. Постараюсь, конечно, но это скорее поток мыслей для коллег, бороздящих просторы большого театра интернета в поисках вдохновения для каких-то собственных проектов.
Каждый инженер рано или поздно сталкивается с вопросом: как выкатить новую версию приложения так, чтобы пользователи ничего не заметили, а команда не получила ночной звонок от дежурного.
На первый взгляд выглядит все довольно просто: собрал новую версию, загрузил на сервер и перезапустил сервис. Но как только система начинает обслуживать реальных пользователей, появляются новые требования — минимизировать простой, быстро откатывать неудачные релизы, снижать риски и выпускать изменения как можно чаще.
Именно для этого существуют Deployment Strategies — набор подходов, которые определяют, каким образом новая версия приложения попадает в продакшен. В этой статье разберём самые популярные стратегии деплоя: Recreate, Rolling Update, Blue-Green, Canary и Shadow, посмотрим их плюсы и минусы, а также выясним, в каких сценариях каждая из них действительно полезна.
«Подскажите модель и серийный номер». «Не знаю, где это смотреть». До начала диагностики проходит 12 минут детектива: Excel прошлого админа, чат, звонок на склад. Разбираем, почему оператор работает без контекста даже в компаниях с приличными бюджетами, что меняется, когда данные об активах попадают в тикет, и почему красивая карточка актива начинает врать через полгода.
Рассмотрим пример сборки go приложения для работы в среде Entware на mips-роутерах Keenetic/Netcraze
В современных веб-приложениях хранение файлов часто отдают специализированным объектным хранилищам, таким как S3. Это удобно, масштабируемо и надежно. Однако здесь возникает классическая проблема проектирования: как обеспечить безопасный доступ к файлам, когда архитектура требует, чтобы хранилище было приватным, а бизнес-логика прав доступа — централизованной? Оставлять S3-бакет публичным — плохая практика, а проксировать каждый запрос на скачивание через бэкенд-сервис — значит, превратить его в «бутылочное горлышко», которое неизбежно захлебнется при росте трафика.
В этой статье я познакомлю вас с реализацией бэкенд-сервиса, который решает эту проблему элегантно: S3 отвечает за хранение и отправку данных, а мое приложение — за проверку прав и генерацию одноразовых, короткоживущих ключей доступа (Pre-signed URL). Я разберу архитектуру решения, покажу, как настроить безопасное разграничение доступа между публичными и приватными объектами, а также продемонстрирую механизм, который позволяет клиентам скачивать файлы напрямую из хранилища, минуя сервер приложения.
Материал будет полезен бэкенд-разработчикам, системным архитекторам и DevOps-инженерам, которые сталкиваются с задачами организации безопасного хранения и выдачи файлов, ищут способы снижения нагрузки на API своего сервиса и стремятся построить надежную систему разграничения прав доступа с использованием современных объектных хранилищ.
Немного практики для "пощупать" HPA в кластере, поиграться параметрами масштабирования. Можно было бы быстро перейти от теории к практике, ну или наоборот. В примерах используется масштабирование на основе очереди RabbitMQ. Можно использовать minikube, MicroK8s, или где вам удобно... Для удобства развёртывания примеры k8s-hpa-rabbitmq-demo.