Представьте, что ваш бизнес обслуживает более 500 компаний, у каждой из которых есть тысячи или даже десятки тысяч клиентов. И все они ежедневно обращаются в клиентскую поддержку через телефон, почту, соцсети, мессенджеры и т. д.
Ваша задача — сделать так, чтобы поддержка стабильно работала даже под высокой нагрузкой, персональные данные были в безопасности, а важная информация случайно не пропала. Справитесь? Вот платформа Юздеск справляется на инфраструктуре Selectel.
К концу 2024 ICL Services завершила проект миграции 150+ тысяч рабочих мест госслужащих Татарстана на ОС Astra Linux. Обойдя 10 конкурентов, этот проект стал победителем в номинации «Лучшее отраслевое решение/Госуправление» конкурса «Проект года» от Global CIO!
Об этом, а также как мы выполняли проекты для нашумевших Игр Будущего-2024, Чемпионата Мира по Футболу FIFA 2018 и Универсиады в Казани в 2013 году, побеседовали руководитель отдела сетевых технологий Олег Цыганов и замдиректора по развитию бизнеса ICL Services Азат Фахрутдинов.
Так звучит девиз современного бизнеса, ведь проблемы с бесперебойностью инфраструктуры чреваты потерей репутации, клиентов и прибыли.
Благодаря поддержке создания HA-кластеров платформа VMmanager позволяет построить безопасную и отказоустойчивую виртуальную среду. Даже если по какой-то причине сбой все же произошёл, ни один процесс не пострадает.
Всего несколько секунд и все данные будут мигрированы с мощностей, которые временно вышли из строя, на рабочие ресурсы без потери производительности. 😏
Рассказали подробнее, как работают HA-кластеры в VMmanager в нашем новом видео.
Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей IP-сети на немаршрутизируемых IP-адресах (10.0.0.0/8, 192.168.0.0/16 и т.д.). Микросервисы разговаривают друг с другом по TCP, подключаясь по IP-адресам, указанным в соответствующих конфигурационных файлах каждого. Но можно указать и не IP-адрес, а некий хостнейм, прописав его же в /etc/hosts. Почему-то часто считают, что "хостнейм эквивалентен IP-адресу". Оно, конечно, удобно так считать, с точки зрения "человекопонятности", но не всегда хорошо с точки зрения безопасной настройки.
Дело в том, что опечатка (или намеренная замена символа) в имени хоста может привести к тому, что адрес окажется в чужой DNS-зоне. Простейший случай: users-db.example.com -> users-db.example.co. Да, должно быть закрыто, да, есть .local, а хостнеймы можно записывать одним "лейблом", но это не решает проблему: использование символьного хостнейма гарантирует дополнительные запросы для разрешения имён, будь то локальные запросы на той же машине или запросы внешние, возникшие из-за опечатки. А всякий, даже локальный, библиотечный/системный вызов, выполняющий трансляцию имён и адресов, готов принести с собой неожиданные эффекты (см. ниже пример уже про IP-адреса). Не обязательно это эффекты от подмены библиотеки или подмены конкретного вызова. А если кто-то умеет записывать в /etc/hosts, то он и конфиг любой поправит. Что, впрочем, не всегда так, поскольку раскладывание hosts по машинам могут автоматизировать - тогда перехватить нужно только точку управления скриптом, формирующим файл. А ведь ещё обычно используется два протокола: v6 и v4, адреса и "резолвинг" там разные.
Если в конфигах микросервисов прописывать непосредственно IP-адреса (пусть и автоматом), то ситуация несколько лучше. Есть неплохие шансы, что трансляция имён/адресов не будет использована. Минимальная опечатка в записи немаршрутизируемого адреса реже приводит к тому, что трафик убегает наружу. Это так потому, что, во-первых, на то они и немаршрутизируемые; во-вторых, в таких системах обычно настраивают различные ACL, а они настраиваются для IP, в других местах, не на конкретной машине с микросервисом, да и пальцы у настраивающих ACL дрожат по-иному.
Тут, впрочем, необходимо отметить некоторые тонкости: ping 010.010.010.010 -- на многих и многих системах отправит пакеты в сторону серверов Google (проверьте). Я раньше рекомендовал использовать этот довольно хитрый "оборот" в рамках собеседований на должность сетевого инженера/разработчика (теперь уже смысла, понятно, нет), поскольку понимание того, почему здесь пакеты уходят в сторону сети Google, раскрывает основную часть опасений, связанных с использованием имён хостов в конфигах. Но всё же, в 010.010.010.010 - более одной "опечатки".
Как мы сокращали количество запросов по фичам в API
Контекст: я отвечаю за разработку конструктора Telegram-приложений. Начинались мы как конструктор кликеров (еще до хомяка). Со временем эволюционировали в конструктор курсов, сообществ, визиток, мероприятий и любых других приложений
Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID
За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.
Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.
Примерно вот так:
GET /users/user
// Response
{
"tgUsername": ...,
"tgId": ...,
...
}
GET /users/features/quizzes/completed
// Response
{
"completedQuizzes": ...,
}
GET /users/features/pages/bought
// Response
{
"boughtPages": ...,
}
GET /users/features/rates/rate
// Response
{
"userRate": ...,
}
При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота
Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка
Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:
не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);
если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);
берём общие часто запрашиваемые данные из кэшей.
Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.
---
Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.
Приложение «МойОфис Документы для ОС Аврора» версии 5.х получило сертификат ФСТЭК России
Приложение «МойОфис Документы для ОС Аврора» успешно прошло сертификацию ФСТЭК России. Теперь на устройствах с операционной системой версии 5.1.0.124 и выше можно использовать защищенную версию приложения МойОфис.
Сертификат подтверждает, что «МойОфис Документы для ОС Аврора» соответствует требованиям четвертого уровня доверия в сфере информационной безопасности (УД 4). Приложение может применяться:
в значимых объектах критической информационной инфраструктуры 1 категории;
в государственных информационных системах 1 класса защищенности;
в автоматизированных системах управления производственными и технологическими процессами 1 класса защищенности;
в информационных системах персональных данных при необходимости обеспечения 1 уровня защищенности персональных данных и в информационных системах общего пользования II класса.
Сертификация распространяется на версию «МойОфис Документы для ОС Аврора» 1.6.1.
Защищенная работа с документами на ОС Аврора
Приложение позволяет пользователям работать с документами на мобильных устройствах в безопасной среде. Компании-заказчики могут внедрять «МойОфис Документы для ОС Аврора» в доверенный контур, создавая защищенные рабочие среды, соответствующие требованиям ФСТЭК России. Это особенно важно для организаций, работающих с критически важной информацией, персональными данными и государственными системами.
«МойОфис Документы для ОС Аврора» — это нативное приложение, которое позволяет редактировать текстовые документы, таблицы и презентации без подключения к интернету.
Что умеет приложение:
Создавать, редактировать и форматировать документы разных типов и форматов;
Работать с таблицами, форматировать ячейки, строить графики и диаграммы, использовать формулы;
Просматривать и изменять презентации, запускать слайд-шоу, использовать таймер демонстрации.
Продукт поддерживает русский и английский языки и совместим с смартфонами и планшетами, а также другими устройствами под управлением ОС Аврора версии 5.1.0.124 и выше. Тестирование приложения производилось на оборудовании НИИ «Масштаб».
Как работает современный RAID-массив: разбираем реализацию YADRO
Чтобы обеспечить доступность данных, T-RAID решает определенный набор задач.
Построение пула хранения на несколько петабайт. Эту возможность обеспечивает архитектура T-RAID: схемы расположения данных, реализация страйпов и allocation-групп дисков.
Оптимизация ребилда дисков и нагрузки на них. T-RAID проводит ребилд только реальных данных, а также распределяет нагрузку ребилда на несколько дисков. Здесь задействована обработка ошибок через блоки, а также фоновые процессы recovery и balancer. В распределении нагрузки помогает фоновый воркер rate limiter и адаптивный троттлер фоновых процессов.
Защита от выхода из строя аппаратных компонентов СХД (процессора, материнской платы, блока питания, контроллера, системного диска). Достигается посредством двухконтроллерной работы в режиме active-active. Тома блоков доступны на запись и чтение одновременно с двух контроллеров при балансировке нагрузки к лунам. Реализацию active-active мы раскроем в отдельной части материала.
Обеспечение отказоустойчивой работы с самими данными от получения запроса до записи в диск. Это реализуется с помощью integrity-механизмов.
Отработка отказов оборудования. Здесь возможно несколько сценариев разного масштаба — от потери отдельного диска до потери целого контроллера или интерконнекта.
О том, как в T-RAID реализованы все перечисленные технические средства, в своей статье подробно рассказал Вячеслав Пачков, ведущий инженер по разработке ПО в департаменте СХД YADRO.
Много лет назад, устав от постоянных тормозов Windows, открыл для себя существование UNIX, точнее, FreeBSD. Иксовый десктоп, все программы - на том же компьютере всё летало заметно быстрее. Даже Quake (да, он тоже работал во Фре).
Куда-то пропали все тормоза. К тому же всё оказалось проще настраивать - у каждой программы свой конфиг, и если что-то где-то даже настроил не так - все остальные программы от этого работать не перестают. Да, пришлось переходить на совсем другой набор программ, далеко не все игры можно было запустить и так далее - но всё равно было быстрее и удобнее работать.
ИМХО, самое главное отличие было как раз вот в этом: в то время как в мире Windows активно продавливали идею "интегрированной среды", где всё вместе и взаимосвязано в монолит - там работал подход "одна задача - одна программа". И если программа не работает как хочется - меняется на аналог, не затрагивая всего остального. Почти любую сложную задачу можно было разбить на отдельные мелкие и подобрать набор утилит для ее решения - как кто-то метко выразился - "стройная система костылей и подпорок".
И вот прошли годы. Уже Линукс (прежде всего из-за лучшей поддержки разного железа), Убунта, которая с каждой версией становилась всё замедленнее и усложненнее.
Видимо, программисты из мира Windows принесли своё вИдение прекрасного: появились D-bus, systemd, gsettings - теперь далеко не всегда можно поправить конфиг-файл от программы XXXX, а потом смотреть в лог /var/log/xxxx.log - нет, теперь настройки хранятся где-то в скрытом месте и меняются специальными командами, а лог полагается смотреть через специальную утилиту, и запускается всё это не простым скриптом типа пошагового выполнения /etc/rc.local, а набором команд systemctl, которые сработают или не сработают, в зависимости от наличия определенных файлов в нужных местах...
А самое главное - после проведенной "интеграции" всё стало тормозить и глючить. Задумчивый Gnome медленно и печально открывает окошки - ага, с экраном повернутым на 90 градусов. Потому что новая "интересная фишка" - считывать датчик ориентации экрана, но считывается он не всегда правильно, а "просто закомментировать в конфиге" нельзя, можно только через меню, потом Сохранить, а потом настройка опять вдруг слетает после незаметного автообновления, которое как бы отключено, но не совсем... Погодите-ка, что-то это мне напоминает? Шаманство, глюки, неустранимые достоинства, "слетевшие драйвера"...
Правда, можно повыключать всё это вместе с Гномом - и всё снова быстро летает: ок, так и сделал, вернул любимый WindowMaker, всё прекрасно. Но вот обновление версии какой-то программы - а новая теперь только через flatpak, а ему теперь необходим d-bus, "если его нет можно поставить эмулятор", блаблабла...
Но зачем?! Зачем было делать из Linux такой же интегрированный сам в себя монолит, с неким "реестром" настроек и "системным журналом", в который нельзя просто так посмотреть? Для этого уже есть Windows! Зачем тащить это сюда?
Мы продолжаем переход от моделей хостинг-провайдеров в части работы с облачными ресурсами. Вслед за формированием облачной платформы на OpenStack с широким перечнем предлагаемых продуктов в 2023 году и выделением автономного облачного и инфраструктурного раздела на сайте в 2024, переходим от свойственной хостерам тарифной сетки.
В новой модели стоимость услуг будет определяться типом и объемом заказанных ресурсов, а не тарифным планом или набором опций. Теперь при заказе облачных услуг можно будет увидеть детальный перечень ресурсов и их стоимость, независимо от тарифного плана, что поможет лучше выбирать и контролировать нужный объем мощностей.
Кроме того, в отдельную услугу будет выделен плавающий публичный IP-адрес. Ранее сервис входил в тариф и отдельно не учитывался. Сейчас за него будет взиматься фиксированная стоимость и при желании от него можно отказаться. А это значит, что сохранится принятый на рынке облаков принцип Pay-As-You-Go и выгода для услуг, работающих полный месяц.
⌨️ КАСТОМНЫЙ МАППИНГ КЛАВИШ В ЛИНУКС: ПРЕВРАЩАЕМ IJKL В СТРЕЛОЧКИ
Для навигации в среде разработки я использую использую маппинг ijkl на стрелочки и оказывается можно сделать этот маппинг на уровне всей ос, а не только IDE.
Маппить будем с помощью xremap (подходит для Wayland и X, простая конфигурация в yaml, написан на расте). Я буду показывать процесс настройки для федоры, но для других дистрибутивов он похожий.
🔧 Создаем конфигурационный файл, который замапит клавиши ijkl на стрелочки при зажатом капсе:
virtual_modifiers:
- CapsLock
keymap:
- remap:
CapsLock-i: Up
CapsLock-j: Left
CapsLock-k: Down
CapsLock-l: Right
CapsLock-h: Home
CapsLock-semicolon: End
CapsLock-u: PageUp
CapsLock-o: PageDown
МойОфис признан одним из лидеров рынка облачного офисного ПО в России по результатам исследования TelecomDaily
Компания МойОфис заняла лидирующие позиции среди поставщиков облачного программного обеспечения для офисной работы в России. Независимое исследование рынка виртуальных офисов, проведенное аналитическим агентством TelecomDaily, охватило 1050 представителей бизнеса, работающих с облачными офисными сервисами, и выявило ключевые тенденции и предпочтения пользователей.
Согласно опубликованным данным TelecomDaily, индекс NPS (готовность пользователей рекомендовать решение к использованию) для продуктов МойОфис составил 56%. При этом, бренд МойОфис является одним из самых узнаваемых на рынке: 52% респондентов знают о его существовании. Больше трети опрошенных компаний (33%) рассказали, что использовали решения МойОфис.
Также МойОфис занял второе место по числу пользователей, планирующих переход на данное офисное ПО в течение года. Согласно опросу, 18% респондентов рассматривают решения компании как приоритетный выбор для обновления офисного пакета.
Исследование выявило, что стабильность работы, безопасность данных и удобство интерфейса являются главными факторами при выборе платформы для организации офисной работы. Эти критерии являются приоритетными при разработке и развитии решений МойОфис, что позволяет компании предлагать продукт, полностью отвечающий потребностям современного бизнеса.
Быстрое трудоустройство в YADRO для разработчиков на С++
У нас стартовал SPRINT OFFER в команду разработки телеком-оборудования. Для «плюсовиков» это возможность получить предложение о работе всего за несколько дней. Если хотите пропустить долгие этапы собеседований, отправляйте заявку до 9 марта.
Как все происходит
Подаете заявку — мы оперативно рассматриваем анкеты.
Проходите HR-скрининг и техническое интервью — без недель ожидания между этапами.
Получаете оффер — если все этапы успешно пройдены, предложение будет у вас в течение 3 дней.
Где предстоит работать
Дивизион телекома создает решения для мобильных сетей. Инженеры разрабатывают базовые станции GSM/LTE, полный стек телекоммуникационных протоколов, а также системы управления и мониторинга. Большую часть кода разработчики пишут на C++. В зависимости от задачи они используют как современные возможности C++20, так и низкоуровневые оптимизации для повышения производительности.
Кого мы ищем
→ Software Engineer (Telecom Platform)
Требуемый уровень: middle, senior, tech lead.
Чем предстоит заниматься:
Разработкой платформы для базовых станций LTE/GSM (middleware, high availability, node management, delivery).
Проектированием архитектуры, работа с C++/Linux.
Интеграцией с аппаратной и программной частью системы.
Оптимизацией кода и решение проблем производительности.
Разработкой API, unit-тестирование, документация.
→ Software Engineer C/C++ (LTE/GSM)
Требуемый уровень: middle, senior, tech lead.
Чем предстоит заниматься:
Разработкой программного обеспечения для базовых станций LTE.
Реализацией стека протоколов 3GPP.
Интеграцией с другими системами, оптимизация кода.
Решением задач производительности и стабильности системы.
Подробнее о вакансиях и команде читайте на странице SPRINT OFFER. Успейте подать заявку до 9 марта!
🗓 01.03 — День хостинг провайдера в России [вехи_истории]
Профессиональный праздник всех, кто обеспечивает бесперебойную работу сайтов, серверов и интернет-сервисов. Хостинг-провайдеры играют ключевую роль в современной цифровой экосистеме, предоставляя услуги по размещению веб-ресурсов, обработке данных и обеспечению их доступности для пользователей.
🗓 01.03 - День хостинг провайдера в России
Без надежногохостинга невозможно представить работу онлайн‑магазинов, корпоративных сайтов, облачных сервисов и социальных сетей.
💙 Ставим лайк и говорим им спасибо — пусть они не падают)
🚀 Как выжать 1,5 миллиона IOPS из базы данных в облаке? Расскажем на бесплатном вебинаре
Приглашаем DBA-инженеров, системных администраторов, DevOps-инженеров и всех, кого интересует работа с облачными базами данных. На практических кейсах и расчетах покажем, как одновременно в 10 раз увеличить производительность баз данных (до 1,5 млн IOPS) и сократить расходы на инфраструктуру почти вполовину. Регистрируйтесь и подключайтесь из любой точки мира 13 марта в 11:00 (МСК).
Что будет на вебинаре
🔹 Сравним выделенную инфраструктуру с классическим облаком.
🔹 Расскажем про подбор железа и оптимизацию ОС для максимальной производительности облачных баз данных.
🔹 Поделимся сравнением производительности баз данных на выделенном облачном сервере с аналогичными сервисами.
🔹 Покажем, как сократить расходы на инфраструктуру для баз данных практически вполовину.
DevOps-инженеры, зовём на публичное собеседование на Хабр Карьере
Это что-то вроде тестового собеседования, в конце которого эйчар дает соискателю развернутый фидбек о том, где он ответил круто, а где — слабые места, которые нужно подтянуть. Отличная возможность проверить свои силы, набраться опыта в собеседованиях и получить обратную связь.
Кого ищем сейчас: middle+, опыт с Linux, Docker, Ansible и Kubernetes. Если вы хотите принять участие и выйти с нами в прямой эфир, откликайтесь здесь.
Заканчивается февраль, и мы знакомим вас с обновлениями на платформе, которые произошли за прошедший месяц.
Продолжаем развивать функционал для сетевых дисков. Добавлена поддержка работы в режиме ReadWriteMany и ReadWriteOnce, что позволяет выбрать оптимальный режим работы сетевого диска в соответствии с потребностями запущенного приложения. Также мы обновили сервис метрик для дисков, повысили точность данных и добавили поддержку новых режимов (RWM и RWO).
Обновлено ПО для «Сетевые сервисы / Порты», увеличена скорость работы сервиса, оптимизировано потребление памяти и процессора.
В веб‑интерфейс панели управления добавили визуальное предупреждение об исчерпании лимита памяти для контейнера. Теперь вы можете явно видеть, что потребление памяти контейнером приближается к лимиту и оперативно отреагировать (например, увеличить лимит памяти для контейнера), это позволит избежать остановки контейнера по причине дефицита ресурсов (out‑of‑memory).
И немного косметики: для логов контейнера и вывода Web‑CLI заменили шрифт на моноширинный, что улучшило чтение данных.
Dockhost— облачная платформа для хостинга приложений на основе Docker-контейнеров (боты, сайты, базы данных и т.д.), которая позволяет запускать и масштабировать как простые проекты, так и сложные микросервисные приложения без необходимости настраивать и контролировать инфраструктуру.
Orion soft обновил промышленную СУБД для высоконагруженных систем Proxima DB
Что нового в версии Proxima DB 3.1:
Мониторинг производительности в UI в режиме реального времени — поможет молниеносно выявлять и проводить траблшутинг зависших запросов, что особенно важно для бизнес-критичных систем
Proxima DB Advanced — полноценная платформа, которая поддерживает совместимость с СУБД на базе PostgreSQL
Возможность развернуть СУБД в контейнерной среде «по клику» за секунды из UI — облегчит и ускорит работу с СУБД в компаниях с собственной разработкой
Подробнее о новых фичах и исправлениях расскажем на вебинаре 12 марта.
Присоединяйтесь! Регистрация на вебинар — по ссылке.
Также в планах — развивать шардирование, геокластеры и дополнять продукт новыми функциями мониторинга (например, рекомендации по оптимизации производительности, карта фрагментирования объектов, интерактивный мониторинг репликаций, мониторинг шардирования).
Let's Encrypt больше не будет отправлять уведомления по электронной почте об истечении срока действия сертификатов
письма счастья от Let’s Encrypt
Ну что ж, вот и кончилась эпоха... С момента своего создания Let’s Encrypt отправлял уведомления об истечении срока действия сертификатов по электронной почте подписчикам, которые предоставили им свой адрес. Однако, начиная с 4 июня 2025 года, данная рассылка будет прекращена.
Let’s Encrypt приводит следующие аргументы в поддержку этого решения:
За последние 10 лет подавляющее большинство подписчиков внедрили автоматизированные системы обновления сертификатов, которые являются более надёжными, чем получение уведомлений по электронной почте.
Для рассылки уведомлений Let’s Encrypt вынужден хранить миллионы адресов электронной почты, что негативно сказывается на конфиденциальности. Сокращение объёма хранимых данных рассматривается как приоритетная задача.
Отправка уведомлений обходится в десятки тысяч долларов в год — средства, которые можно использовать гораздо эффективнее для улучшения других компонентов инфраструктуры.
Поддержка системы рассылки увеличивает общую сложность инфраструктуры, требуя дополнительных ресурсов и повышая вероятность ошибок. С учётом планов по внедрению новых функций становится необходимым сокращение избыточной сложности инфраструктуры.
Для тех, кто хочет продолжать получать уведомления об истечении срока действия сертификатов есть возможность воспользоваться сторонним сервисом Red Sift Certificates Lite (https://redsift.com/pulse-platform/certificates-lite). Мониторинговый сервис Red Sift предоставляет уведомления бесплатно для 250 сертификатов.
Несмотря на заявленное стремление сокращать количество хранимых адресов для рассылки уведомлений об истечении срока действия сертификатов, рассылки о новостях Let’s Encrypt и ее материнской компании ISRG (https://www.abetterinternet.org/) не прекратятся... А те кто не успел на них подписаться даже могут это сделать. Правда, как это сочетается с желанием сократить общую сложность инфраструктуры, я уже не могу и предположить.
Для тех, кто еще не добавил автоматическое обновление сертификатов на свой сервер – вот подходящая команда для cron (пытается обновить сертификаты через каждые трое суток):
