От звонка до лайка: опыт создания техподдержки. Часть 2

Продолжаем серию о том, как мы строили техподдержку с нуля. На повестке вопрос, который вызвал много споров внутри команды: описание обязательств по доступности услуг и финансовых гарантий в договорах.

Важно было определиться: что отличает доступную услугу от недоступной в глазах клиента, какой уровень доступности мы гарантируем, что входит (и что не входит) в расчет, а также разобраться, как посчитать фактическую доступность.

Сегодня наш директор техподдержки Ирина Курбатова рассказывает, к чему Облакотека пришла.

1️⃣ Как мы понимаем, что услуга доступна

Наши клиенты определили такие критерии:

☑️ Можно подключиться. Услуга отзывается с предусмотренными параметрами, это происходит с должной скоростью, и канал связи обеспечивает согласованную в SLA ширину полосы.
☑️ Производительность соответствует заявленным показателям. Например, для IaaS: производительность процессора, параметры дисков — скорость операций чтения/записи, задержка от запроса на операцию до ответа на нее, пропускная способность.
☑️ Можно самостоятельно управлять услугой. Остановить или возобновить работу, изменить параметры услуги — количество ресурсов, их тип, глубину бэкапа.
☑️ Удобно управлять дополнительными опциями. Речь про библиотеку образов, развертывание из шаблона, подключение инструментов безопасности и надежности и других функциях.

2️⃣ Как определяем гарантированный уровень доступности услуг

В Облакотеке почти везде этот показатель составляет 99,9%. Но все зависит от компонентов конкретной услуги. Например, гарантии могут быть ниже, если использовано прикладное ПО внешнего вендора или standalone-архитектура.

Мы все это описываем в приложении к типовому договору. А еще по запросу клиента подбираем решения с более высокой доступностью.

3️⃣ Почему проводим профилактические работы

Чтобы услуги были безопасными и надежными, важно регулярно проводить профилактические работы. Например, применять обновления безопасности на компоненты инфраструктуры.

Мы стремимся создавать архитектуру так, чтобы профилактические работы не отражались на доступности сервисов. Но иногда они могут привести к снижению производительности или недоступности услуги. Такие ситуации не учитываются в расчете финансовых гарантий.

Чтобы такие ситуации не влияли (или почти не влияли) на клиента, профилактические работы организовывают таким образом, чтобы:

⏺ время снижения производительности или недоступности не превышало 2 часов в месяц;
⏺ клиенты были предупреждены за 3 рабочих дня;
⏺ работы проводились по выходным, праздникам или в будни после 22.00 МСК.

4️⃣ Как рассчитываем фактическую доступность

Период расчета — календарный месяц. Берем промежуточные показатели:

А: количество минут в месяце, когда услуга была недоступна или ограниченно доступна. Этот показатель определяем по системам мониторинга и по обращениям клиентов.
В: сколько всего минут в месяце (зависит от количества дней).
С: доля времени недоступности услуги за период. То есть А разделить на В.

Доступность считаем по формуле: (1- С)*100%.

Если этот показатель оказывается менее гарантированного (обычно 99,9%), то превышение округляем до часов в большую сторону (в пользу клиента). За каждый час ​​недоступности возвращаем 1% стоимости услуги за месяц.

#Ирина_поддержи

⚒️ Дилемма молотка и отвертки: выбор между S3 и HDFS для больших объемов данных

В статье на Вайти CEO Облакотеки Максим Захаренко рассказал о двух легендарных технологиях, которые пришли из разных миров, но плотно сплелись в общем поле задач и функций. В чем разница и что выбрать — пересказываем в формате поста.

Объектно или распределенно?

⏺ Объектное хранилище класса S3 — универсальный интерфейс облачного хранения; его поддерживает и Облакотека (наш S3-совместимый сервис). Это как бесконечные шкафы с запечатанными коробками-объектами, каждую из которых можно сложить или забрать только целиком: быстрый и удобный доступ без шансов сразу разобрать и обработать контент внутри.

⏺ Распределенная файловая система HDFS из мира big data — как мастерская со своим складом под боком. Она режет файлы на блоки и раскладывает по множеству «полочек», чтобы проводить частые вычисления в тяжелых аналитических «мельницах» напрямую с места хранения.

Гибкость или скорость?

⏺ S3 почти идеален, когда нужно надежное хранилище: легко искать, поддерживать и масштабировать. Вы складываете данные в облако, они доступны разным командам, приложениям, внешним сервисам — об остальном думает провайдер. Гибко и просто: то, что надо, если вы не рветесь заниматься своим железом.

⏺ Если же речь об интенсивной обработке, частом чтении и записи в реальном времени, первым выбором может стать старый добрый HDFS. Когда сотни узлов жуют терабайты данных, нужна минимальная задержка и гарантия мгновенного доступа. HDFS обеспечивает быструю работу с гигантскими массивами, ведь файлы хранятся локально и сразу доступны всем узлам кластера.

Дилемма или синергия?

⏺ Один из клиентов Облакотеки копил десятилетия статистики, логов и копий. Мы вынесли архивы в объектное хранилище: теперь компания платит «за фактическое потребление», избавилась от головной боли с железом и администрированием и сосредоточился на анализе свежих данных.

⏺ Другой клиент — стартап в сфере VR и 3D-контента, каждый день генерит терабайты сырых видео и телеметрии. Ему нужно не только хранить, но и быстро обрабатывать данные: строить модели, анализировать и вести ML.

Стартап пытался складывать информацию в облако, но быстро понял, что не хватает скорости отдачи при анализе. Поэтому компания развернула собственный Hadoop-кластер на платформе Облакотеки: система собирает данные в HDFS и сразу крутит все вычисления прямо там.

⏺ В последнем примере обработанные результаты и исторические пласты данных теперь текут обратно в S3, чтобы их долго хранили и делились ими по запросу сервисов. Так мы выжали максимум из обеих технологий, не отказываясь от сильных сторон ни одной из них.

➡️ S3 и HDFS — как молоток и отвертка: оба нужны в ящике инструментов, и стоит знать, как и когда их применять, чтобы достигать конкретных целей с максимальным эффектом.

#дорогой_бэклог

Едем в айтишное роад-шоу: го с нами на борт?

Начать деловой сезон с путешествия по городам и весям ИТ-конференциям – это по-нашему. Рассказываем, где будет выступать «Облакотека», а главное – с чем. В конце поста приятный бонус для подписчиков.

⏺«Стачка» в Петербурге — 2–3 октября

Более 3000 специалистов соберутся поговорить о разработке, управлении, дизайне и digital-маркетинге. «Облакотека» – куратор секции DevOps. Наш эксперт Роман Гаян выступит с темой: «Kubernetes Flex: размер имеет значение». Расскажем, как подобрать кластер под задачи.

Ну и весь день ждем на стенде Облакотеки: покажем демо, прикинем экономику под ваш кейс, обсудим миграции и бэкапы.

⏺ Tech Support Conf ‘25 в Петербурге — 14 октября

Здесь все про техподдержку: первая практическая конференция в России, где специалисты разберут реальные проблемы саппорта.

От нас будет руководитель техподдержки Ирина Курбатова – она же автор рубрики #Ирина_поддержи. Обсудим, как превратить SLA из формальности в рабочий инструмент. Отличная возможность попросить автограф, пообщаться с Ириной онлайн и задать вопросы.

⏺ Merge в Светлогорске и Москве — сентябрь–ноябрь

Заезжаем на Merge, чтобы охватить одним разом все сферы ИТ – от разработки до HR: всего 30 (!) секций. Мы уже отметились в Оренбурге, следующие точки – Светлогорск (17–19 октября) и Москва (14–15 ноября).

Нас будет трудно не заметить: ищите на стенде облачных кибер-женщин, офисных on-prem зомбаков и крутые подарки.

⭐️ И тот самый приятный бонус

Договорились с организаторами о промокодах. Заветное слово Oblakoteka при покупке билетов на любое мероприятие даст скидку 10%.

#куда_мы_заехали

Жизнь после релиза: все только начинается

Чуть раньше мы рассказывали, какой путь от идеи и до первого запуска проходит облачный сервис. Сегодня поговорим с Оксаной Новицкой о том, что же происходит дальше.

Кажется, что если сервис работает, есть первые клиенты и обратная связь, то можно выдохнуть. Но нет!

Только через время начинается самая непредсказуемая часть: реальная эксплуатация под большими нагрузками, неудобные вопросы, разнообразные сценарии использования. Мы заранее никогда не знаем, что именно клиенты придумают.

1️⃣ Поддержка как часть запуска

Сразу после старта работы объектного хранилища в поддержку полетели вопросы. Например, как ограничить доступ только для одного IP или можно ли привязать свое доменное имя к хранилищу.

Это не баги, но каждый вопрос требует ответа и/или серьезной доработки сервиса. Например, мы долго думали над возможностью привязать к хранилищу доменное имя. И, кстати, до сих пор не реализовали эту возможность. Но несколько идей и примерный план доработок уже есть.

Другие вопросы тоже были не самые простые. Мы дописывали базу знаний, разбирались в настройках, что-то автоматизировали и подпиливали руками.

Стало ясно: поддержка — это не то, что идет после релиза. Это часть запуска, и без нее сервис не работает.

2️⃣ Метрики из реальной жизни

Тесты — одно, продакшн — совсем другое. На графиках вскрылись интересные картины: один клиент пишет один файл в день, второй — тысячу объектов в секунду, а третий подключил специфическое бэкапное ПО, которое неадекватно реагирует на смену уровней хранения. Что сделали:

➡️ перестроили алерты, чтобы ловить не только ошибки, но и аномальные нагрузки;
➡️ пересобрали архитектуру;
➡️ добавили отчеты и стали чаще смотреть мониторинг вживую.

3️⃣ Факапы и как с ними бороться

Ошибки после релиза неизбежны, и важно правильно на них реагировать.

Да, мы пропустили ситуацию с ростом нагрузки. Алерт сработал, но был слишком немым: просто «Ошибка есть». Команда несколько часов разбиралась, пока не поняла, что проблема в резком скачке запросов. Вывод сделали сразу: алерты должны быть умными, а не формальными.

Еще одна классика — документация. Мы считали ее достаточно понятной, пока не пришел первый клиент и не задал вопрос, на который вроде бы есть инструкция, но первая линия не смогла ответить. Оказалось, что написанное понять сложно. После пары таких историй начали переводить инструкции на человеческий язык.

4️⃣ Хотелки или roadmap?

Пока мы чинили баги и настраивали систему, начали приходить запросы: сделать версионирование объектов, дать публичный доступ по ссылке. Сначала улыбались, потом записывали. В итоге поняли: это не хотелки, а roadmap. Каждый запрос — это реальный кейс клиента и готовое направление развития.

5️⃣ От отдельного сервиса к экосистеме

Объектное хранилище довольно быстро перестало быть самостоятельной коробочкой. Его начали встраивать в бэкапы виртуалок, логирование Kubernetes, внешние системы через API. Команда взялась писать инструкции, примеры, готовить своего Terraform-провайдера.

MVP живет недолго. Минимальный функционал и стабильная работа устаревают буквально через несколько недель. Клиенты приходят не за интерфейсом или API, а за решением задач. Поэтому жизнь после релиза — это марафон, где запуск — это только стартовый выстрел.

#Оксана_объясни

Первый ИИ-министр: албанский эксперимент

Албания стала первой страной, официально назначившей искусственный интеллект на должность члена правительства. Новый цифровой «министр» по имени Диэлла будет отвечать за государственные закупки. Мол, это поможет сделать тендеры свободными от коррупции.

Верить или не верить в это сказочное будущее — дело ваше, а наше — рассказать, что мы об этом думаем. Займется этим Владимир Кондратьев, PDE Облакотеки.

⏪ Отмечу, что у Диэллы уже рука набита: с января 2025 года она работала виртуальным ассистентом на портале e-Albania, помогая гражданам решать бюрократические задачи онлайн. Теперь власти доверили ей более амбициозную миссию.

Одни эксперты скептично называют ИИ-министра служанкой гозакупок. Другие менее категоричны, но напоминают: без жестких механизмов контроля ИИ не станет прививкой от коррупции.

Прежде чем высказаться, представлю мнение коллег. Вот что говорит Богдан Сергеев, CEO bogdanna.dev ⬇️:

Модели с каждым годом обрабатывают больше данных — им чужды амбиции, корысть и старение.

Богдан настаивает на open-source-подходе и «ансамблях» из нескольких моделей, которые взаимно проверяют решения, чтобы снижать ошибки и предвзятость. Он считает, что критично качество обучающих данных: без чистого и репрезентативного датасета никакая архитектура не спасет. Такой ансамбль, добавляет он, не впадает в ностальгию про «раньше было лучше», а будет опираться на метрики и проверяемые результаты.

Как по мне, во всем есть свои плюсы и минусы. Начнем с рисков:

1️⃣ Ошибки алгоритма. Система ИИ может давать сбои или выдавать «галлюцинации» — выводы, не соответствующие реальности. Без контроля алгоритм способен совершить неверный выбор победителя тендера, поэтому необходима обязательная проверка его решений человеком.

2️⃣ Киберугрозы и манипуляции. Если не обеспечить надежную защиту, злоумышленники могут вмешаться в работу алгоритма. Правительство пока не раскрыло, каким будет надзор за Diella, что порождает вопросы о возможных уязвимостях системы.

3️⃣ Непрозрачность решения. «Черный ящик» ИИ трудно объяснить и проверить. Также остается вопрос ответственности: кого винить, если автоматизированная система ошибется при распределении многомиллионного контракта?

Но есть и существенные преимущества:

1️⃣ Неподкупность. ИИ-агента нельзя подкупить или запугать — он оценивает заявки строго по заданным критериям (но подкупить можно человека, который этого агента обучает). Власти уверены, что Diella обеспечит честную конкуренцию.

2️⃣ Гласность. Все этапы тендера фиксируются и доступны для анализа: «Каждый публичный фонд, проходящий через тендер, будет абсолютно прозрачен».

3️⃣ Эффективность. ИИ обрабатывает массивы заявок намного быстрее человека, мгновенно проверяя соответствие компаний критериям и отсекая лишние варианты без бюрократических задержек.

❓ А что дальше-то?

Албанский эксперимент привлек внимание соседей: они видят шанс обогнать развитые государства в модернизации госуправления. Если Diella докажет эффективность, ИИ-министры могут появиться в других странах региона.

Консервативные правительства вряд ли скоро передадут ИИ-агентам такие решения — там привыкли к ручному контролю и не всегда доверяют новому. Тем не менее, шаг Албании называют предвестником будущих перемен и успешный пример Диэллы может подтолкнуть скептиков к внедрению подобных технологий ⏩.

⬇️ Что думаете вы? Делитесь мнением в опросе или комментариях.

#взлетит_не_взлетит

Добро пожаловать, Terraform

А у нас пополнение — не так давно мы добавили Terraform в экосистему Облакотеки. Уже даже появился первый фидбек. Сегодня раскроем все карты: зачем это было сделано, как все прошло, что говорят клиенты и какие планы на будущее.

Рассказывает Оксана Новицкая, наш директор по развитию.

⏪ Кажется, что Terraform уже стал индустриальным стандартом. Но решение внедрить его в Облакотеку появилось не сразу. Сначала мы наблюдали, потом слушали клиентов, считали запросы и только после этого начали разработку.

❓Зачем нужен Terraform?

Инструмент позволяет описывать инфраструктуру в виде кода, и это помогает автоматизировать типовые операции. Вместо того, чтобы вручную настраивать виртуальные машины, сети и хранилища, все можно описать в виде кода и разворачивать в считанные минуты.

❓Для кого это важно?

Terraform успешно применяется в самых разных сценариях.

➡️ Тестовые стенды: клиент разворачивает десятки тестовых окружений каждую неделю. Вручную это занимало часы, с Terraform — минуты.

➡️ DR-сценарии: при сбое инфраструктуры ПО дает возможность развернуть копию окружения за считанные минуты, минимизируя простой сервисов.

➡️ Масштабируемые проекты: при запуске или однотипных развертываниях с десятками виртуальных машин и сетевых ресурсов. Решение позволяет автоматически создавать нужную инфраструктуру без ошибок и ручной работы.

➡️ И более сложные сценарии: многоэтапные деплои, команды с распределенным доступом и проч. Без автоматизации такие процессы превращаются в постоянную боль.

Запрос на Terraform звучал от клиентов регулярно. Только за последние полгода мы насчитали более 20 прямых обращений. Плюс на встречах этот вопрос почти всегда вставал — косвенно или напрямую. Мы поняли: это не просто «хотелка», а необходимость. Компании с растущей инфраструктурой уже не могут работать без IaC-инструментов.

❓С чего начали и что уже сделали?

Мы пишем свой Terraform-провайдер, и дело это не очень быстрое. Все началось с базовых ресурсов для объектного хранилища.
В первом релизе появилась возможность создавать хранилище, бакеты, генерировать ключи доступа и загружать объекты. Функционал минимальный, но закрывает основные потребности управления сервисом.

Дальше мы сосредоточились на ресурсах для создания полноценной инфраструктуры.
Cейчас через Terraform можно выполнять следующие операции:

☑️ Создавать ВМ и управлять ими;
☑️ Создавать и настраивать виртуальные сети и подсети, получать публичные IP-адреса;
☑️ Управлять дисками;
☑️ Работать с объектным хранилищем.

Этого достаточно, чтобы начать автоматизировать основные сценарии.

❓Какой фидбек?

Перед стартом мы провели тестирование совместно с партнерами. Они отметили простоту работы: скачал провайдер, подключил в конфиг — и инфраструктура работает.

Но и не обошлось без замечаний. Скорость развертывания была небольшой, указывать IP-адреса надо было вручную, для конфигураций использовалась огромная таблица GUID, и работать с ней было очень неудобно.

Мы взяли замечания в работу и буквально за спринт реализовали улучшения: распараллелили процессы, допилили автоматическое выделение IP-адресов, избавились от GUID, заменив их на интуитивно понятные алиасы. Также реализовали возможность прокидывать SSH-ключи в виртуальную машину — функционал простой, но довольно важный.

Кроме того, в ближайшее время мы планируем расширить документацию, пополнив ее готовыми манифестами и рабочими примерами. А еще в планах добавить поддержку балансировщиков, Kubernetes и расширенных политик безопасности ⏩.

#хвалимся

От звонка до лайка: опыт создания техподдержки. Часть 3

Что стоит за надежностью ИТ-сервисов, которую мы обещаем клиентам в SLA? Это не просто технологии, а выстроенные процессы: анализ рисков, распределение приоритетов, постоянный мониторинг.

Как в Облакотеке создали систему, которая минимизирует простои, рассказывает Ирина Курбатова, директор департамента техподдержки ⬇️.

⏪ При подборе услуг и подготовке SLA для клиентов мы всегда стремимся разобраться, как ИТ-услуга Облакотеки влияет на бизнес-процессы компании, и сделать наши услуги надежной опорой для каждого клиента и партнера.

Обеспечить внутреннюю систему контроля, проактивных мер, регламентов реагирования на угрозы и аварийные ситуации — это кропотливый, непростой, постоянно развивающийся процесс. Для его поддержания в актуальном состоянии мы в том числе используем рекомендации стандартов ISO/IEC 27001 и ISO/IEC 27031, ISO 22301, законодательство РФ в области информатизации, ИТ-услуг, защиты данных.

В Облакотеке доступность, целостность и безопасность ИТ-услуг обеспечивают по двум направлениям:

➡️ BCP (Business Continuity Plan) — проактивно следят, чтобы критически важные элементы инфраструктуры и ПО работали корректно, без сбоев и с высокой производительностью.

➡️ DRP (Disaster Recovery Plan) — быстро восстанавливают сервисы после аварий или любых отклонений от штатного режима.

Чтобы внедрить каждое из направлений, мы:

1️⃣ Описали наши ИТ-услуги, критичные ресурсы и внутренние сервисы, от которых они зависят.

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

2️⃣ Проанализировали, как влияют друг на друга ресурсы и сервисы нашей внутренней архитектуры. Также мы учли компетенции команды и качество документации. После этого подготовили модель угроз и оценили их вероятность.

❗️ Наконец, самая важная часть: мы описали, к каким последствиям приведут сбои, снижение производительности или уязвимости. Определили, как эти риски повлияют на ИТ-услуги, финансы или репутацию компании.

3️⃣ На базе анализа ранжировали все элементы, которые влияют на ИТ-услуги. Установили RTO (recovery time objective) и RPO (recovery point objective), определили приоритетность восстановления каждого внутреннего ресурса или сервиса.

4️⃣ Зарезервировали и продублировали все, что нужно для работы критически важных ресурсов и сервисов. Затем описали, как запускать резервные мощности, и проверили, что процедуры работают.

5️⃣ Установили, какие значения доступности и безопасности для сервисов считаются нормой, а какие — нет. Настроили мониторинг, который помогает это отслеживать (подробнее об этом мы писали здесь).

6️⃣ Создали автоматическое реагирование на сбои. Также предусмотрели процессы с ручной диагностикой. Это позволяет отвечать на проактивные алерты, аварийные инциденты и восстанавливать доступность сервисов».

А предыдущую часть серии можно найти по ссылке.

#Ирина_поддержи

Китай печатает будущее

Любимые сериалы у всех разные: «Игра престолов», «Санта-Барбара», «Доктор Кто»… А вот у нас — «ИИ-суверенитет Китая». В недавнем эпизоде увидели интересный твист: стартап из Шанхая собирается пошатнуть монополию ASML.

В чем суть: SMIC, крупнейший производитель чипов в Китае, начал тестировать первую в стране литографическую машину глубокого ультрафиолета. Сделал ее не гигант с вековой историей, а стартап Yuliangsheng, которому всего-то четыре года.

Разобраться в этой истории нам поможет Максим Захаренко, СЕО Облакотеки.

⏪ Для участия в гонке ИИ по-прежнему требуются вычислительные мощности. Уже несколько лет на Китай наложены экспортные ограничения США и других стран западного кластера, которые существенно мешают развитию в этой сфере.

Мы помним, что производство современных чипов — это многоуровневая экосистема, включающая в себя множество высокотехнологичных производств, в том числе изготовление плат, использование особо чистых газов и др. На вершине этой системы стоит литографическая машина, то есть печатный станок, на котором создаются чипы.

➡️ До сегодняшнего дня единственным производителем современных литографических машин была нидерландская ASML из западного кластера. В Китае есть свои разработки, например, у SMEE, но они не впечатляют: массово делаются машины для 90нм. Заявлялось еще про 28нм, но реального подтверждения так и нет. В то же время машины ASML работают на техпроцессе 7нм, 5нм и даже 2нм.

И вот пришла новость про новую китайскую литографическую машину от стартапа Yuliangsheng. Сразу удивило, что это стартап, образованный всего четыре года назад. Стало интересно, откуда растут ноги, и, конечно, выяснилось: скорее это спин-офф компании SiCarrier, которую связывают с Huawei.

#️⃣ Основной техпроцесс заявленной машины 28нм, но за счет использования технологии т.н. «мультипаттернинга» потенциально можно получить чуть ли не 5нм чипы. Большой акцент делается на локализации компонентов, правда, «некоторые еще закупаются за рубежом». Сейчас разработка на стадии тестирования, а что с промышленным производством — пока непонятно. Где-то проскакивают планы выхода на рынок в 2027 году.

Новостям из Китая нельзя полностью доверять, особенно в такой хайповой теме, как ИИ. Тем не менее, появление таких сообщений — когда как бы из ниоткуда возникает очередной шедевр — говорит об активных и позитивных процессах внутри Китая, направленных на достижение ИИ-суверенитета. А мы продолжим наблюдать за этой темой ⏩.

#Максим_ерунды_не_скажет

🌥 Что нашептали облака: сентябрь

Сегодня время дайджеста: показываем, где засветились и что обсудили за месяц. Для тех, у кого времени как свободных ресурсов в дата-центре в черную пятницу, — сделали короткий пересказ с щепоткой иронии.

0️⃣1️⃣ Цифры месяца — HeadHunter

Когда кадры в дефиците, компании придумывают лайфхаки. В Облакотеке сделали биржу задач, где можно взять дополнительное задание или смену. Маркетологи идут в аналитику, инженеры примеряют продуктовые роли, а саппорт пробует код. Уже 15% задач закрываются «внутри», расходы на рекрутинг снизились на треть, а вовлеченность подросла на 12%.

⚡️ Угроза месяца — Computerra

96% компаний в России уязвимы. Наш СЕО рассказал о причинах: зоопарк подрядчиков, миграции на коленке и надежда на железки вместо процессов. Плюс классика жанра: доступы вечные, бэкапы непроверенные. Подробности — тут.

❗️ Ошибка месяца — SecurityMedia

ZT не равно продукт. Купили «Zero Trust firewall» и думаете, что галочка стоит? Нет, тут философский подход нужен — ИБ-культура, обучение сотрудников, прозрачность. Без управления идентификацией, сегментации сети и постоянного контроля это остается маркетинговой наклейкой. Какие еще есть проблемы с ZT — рассуждали в статье.

⬆️⬇️ Прогноз месяца — GlobalMSK

Сентябрь разворачивает спрос: миграции, оптимизация расходов, Kubernetes и S3 тоже выходят на сцену. FinOps в тренде: считают не только гигабайты, но и TCO. В этом сезоне мы ждем оживление, особенно в промышленности и e-commerce, где растут нагрузки и требования.

На этом наш облачный дайджест растворяется в воздухе. Встретимся в октябре!

#засветились

Есть пара тонкостей

И почему все компании еще не перешли на тонкие клиенты? Размышляли об этом в статье для IT-world и нашли кучу плюсов: TCO, кибербезопасность, управляемость. Меньше спецов нужно, в конце концов. Подробнее читайте по ссылке.

А для тех, кому практику подавай — выбрали из статьи подводные камни, о которые можно споткнуться в проектах с тонкими клиентами ⬇️.

1️⃣ Вопросы архитектуры

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

2️⃣ Смена ролей

Когда компания переходит на тонкие клиенты, меняется и роль ИТ-отдела. Ему придется выполнять функции сервис-провайдера: отвечать за платформу, процессы и уровень сервиса для пользователей.

Профессия ИТ-администратора внутри компании тоже становится другой. Если раньше ценились универсалы, которые умели и починить железо, и поставить софт, то теперь на первый план выходят архитекторы и администраторы сервисов. Нужно разбираться в виртуализации, сетях, безопасности, понимать, как работает автоматизация и оркестрация.

3️⃣ Эксплуатация

Одно из слабых мест в ходе пользования — сеть. Пользователи сразу чувствуют, если канал «проседает».

Еще одна боль — периферия. Тонкие клиенты не всегда дружат с экзотическими принтерами или сканерами. Кажется, что это мелочи, но они превращаются в реальные простои.

4️⃣ Масштабирование

Тоже не всегда проходит гладко. Пока подключена сотня пользователей, все работает идеально. Когда их тысячи, внезапно вылезают узкие места в хранилище или лицензировании. Закладывать запас нужно сразу, иначе переделка инфраструктуры выйдет дороже.

5️⃣ Поддержка тяжелого софта

С классическими программами все понятно: они чаще всего работают стабильно. Но как только речь заходит о специализированном софте, вроде CAD-систем или тяжелой аналитики, начинаются вопросы к производительности. Здесь уже нужны GPU-ресурсы и грамотная настройка.

6️⃣ Безопасность

В теории все хорошо: данные не хранятся на рабочих местах, а остаются в защищенном контуре. Однако нужно учитывать не только физическую защиту данных, но и сетевые риски. Один удачный фишинг или заражение по каналу связи может парализовать доступ сразу для всех пользователей. Поэтому важна комплексная защита: шифрование каналов, двухфакторная аутентификация, контроль доступа, мониторинг событий.

#мы_все_о_своем_об_облачном

Просчитывают на несколько GPU вперед

Сбер и Т-банк пробуют китайские чипы для ИИ, Альфа-банку пока «только спросить», а ВТБ мечтает о технологической независимости от Nvidia. Сейчас китайские GPU тянут базовые задачи вроде скоринга и антифрода, но до (до)обучения больших моделей им далеко. О дальновидности российских банков рассуждает Максим Захаренко, СЕО Облакотеки.

⏪ Тестирование китайских альтернатив в ИИ-центрах крупнейших банков — закономерный шаг. Сейчас практически любые карты Nvidia доступны на российском рынке. При этом существуют потенциальные угрозы: они могут исчезнуть с рынка в будущем или, что более вероятно, вендор может начать их контролировать и отключать удаленно. Поэтому понятно желание как минимум диверсифицировать ИИ-мощности за счет дружественного сегодня нам Китая.

Новость выглядит не очень положительно — пока нет информации, что китайские карты будут реально применяться. Скорее делается вывод, что они пока не подходят (перегреваются и недостаточно стабильны). Понятно, что такой вывод получается из двух составляющих:

1️⃣ Во-первых, действительно, карты могут быть не очень хороши. Мы следим за развитием ИИ-суверенитета Китая в канале и пока не заметили однозначно прорывного продукта.

2️⃣ Во-вторых, новые карты имеют отличный от карт Nvidia программный интерфейс. Обязательно потребуется серьезная переработка и адаптация софта, которая не принесет каких-то особых положительных результатов. Это, как и любое импортозамещение, демотивирует исполнителей. Отсюда появляется множество аргументов, почему нам это не подходит.

Сколько в полученном выводе объективного или субъективного сейчас не так важно, значительно интереснее посмотреть вперед. Всем российским центрам, в которых концентрируется ИИ, в любом случае придется искать замену западным чипам. И источником таких чипов может стать только Китай.

В России ничего подобного не разрабатывается и, по-моему, это даже ушло из дальних планов государственной политики. Собственно, как и нигде больше в мире, включая технологические развитые Европу, Корею и Японию. В гонке чипов только два участника — США и Китай ⏩.

#Максим_ерунды_не_скажет

Когда сгорает «облако государства»

В Южной Корее случился цифровой апокалипсис: пожар в здании Национальной службы информационных ресурсов уничтожил всю ИТ-инфраструктуру страны.
647 государственных сервисов остановились, 96 из них уничтожены. В огне сгорели и данные, и резервные копии.

Ситуация в Корее — страшный сон любого айтишника, поэтому не можем не посочувствовать восточным коллегам. Вместе с тем хотим поразмышлять: что же пошло не так и как можно было застраховаться от рисков. Для этого позвали Оксану Новицкую, директора по развитию Облакотеки.

⏪ Мне кажется, что все сильно преувеличено — все-таки уже сейчас удалось восстановить работу 163 сервисов. Но давайте допустим, что все действительно так и подумаем, как можно было бы минимизировать последствия.

Случившееся — следствие неудачных архитектурных и управленческих решений, которые десятилетиями считались «удобными и дешевыми». Какие ошибки были допущены?

1️⃣ Одна площадка = одна точка отказа

Главная проблема — концентрация всех критичных систем в одном физическом дата-центре. Да, централизованное управление кажется эффективным: проще поддерживать, меньше затрат, понятнее ответственность. Но это иллюзия. Любая инфраструктура, особенно государственная, должна проектироваться по принципу геораспределенности и независимости контуров.

Должно быть минимум два ЦОДа в разных географических зонах, на разных энергосетях, с независимыми каналами связи. Между ними — синхронная или асинхронная репликация с регулярной проверкой целостности данных и сценариями переключения.

2️⃣ Бэкап не спасение, если он где-то рядом

Не стоит хранить резервные копии на соседнем сервере. Типичная ошибка, когда бэкапы воспринимаются как формальность, а не часть стратегии устойчивости.
Бэкапы должны жить в другой зоне отказа, лучше всего в другом ЦОДе или даже у независимого провайдера.

Правильный подход — 3-2-1:
⏺ 3 копии данных;
⏺ 2 разных носителя;
⏺ 1 копия — вне основной площадки.

И всё это с регулярным тестированием восстановления. Если никто ни разу не попробовал поднять систему из бэкапа, то можно считать, что его просто нет. Потому что вообще неизвестно, поднимется ли из него что-то.

3️⃣ Безопасность воспринимается как тормоз, а не как часть продукта

В таком случае инфраструктура превращается в карточный домик. Сценарии аварийного восстановления (DRP), тесты отказоустойчивости, резервные регламенты, дежурные протоколы — все это должно быть не на бумажке для аудита, а реально отработанными практиками.

4️⃣ Отсутствие автоматизации

Система должна быть устроена так, чтобы человеческий фактор не решал, выживет ли инфраструктура. Например, если резервное копирование или переключение на резервный ЦОД зависит от ручного запуска инженером, то это не система, а сценарий надежды.

В зрелой архитектуре такие процессы автоматизированы: при выходе из строя площадки запускается автоматическое переключение на резервную, а бэкапы создаются по расписанию и проверяются независимо от людей.

Так строят инфраструктуру крупные провайдеры и операторы:

➡️ отказ площадки не требует героизма дежурной смены;
➡️ аварийные сценарии запускаются по заранее протестированным политикам;
➡️ ответственность распределена между ролями и системами.

#Оксана_объясни

Гонка за миллисекундами

Приложения реального времени начинают тормозить, видеоконференции сбоить, пользователи VDI ощущают лаги клавиатуры и мыши — а всему виной высокая latency. В материале на Вайти рассказываем, что делают дата-центры и провайдеры, чтобы снизить задержки. А здесь — краткое саммари.

Снижение задержки начинается с инфраструктуры ЦОД. Что здесь важно:

1️⃣ Расположение и связность оборудования. Серверы в ЦОД размещают компактно и используют эффективную топологию (spine-leaf), чтобы сократить длину кабелей и число «пересадок» для данных.

2️⃣ Высокопроизводительное сетевое железо. Провайдеры в РФ используют мощное сетевое железо (Mellanox, Juniper, Huawei) и держат нагрузку на каналах не выше ~70%, чтобы не было тормозов и скачков пакетов.

3️⃣ Изоляция разных типов трафика. Сети в ЦОД сегментируют, выделяя отдельные каналы для служебного (бэкапы, СХД) и клиентского, внешнего и внутреннего трафика. Это предотвращает конкуренцию за ресурсы.

4️⃣ Скорость СХД. Быстрые диски = низкая задержка. Поэтому облачные провайдеры переходят на all-flash хранилища (только SSD/NVMe), что обеспечивает мгновенный отклик для критичных систем вроде 1С и баз данных.

5️⃣ Производительные серверы. Современные CPU, большой запас RAM и высокоскоростные интерфейсы (10–100 Гбит/с) для подключения к сети.

Сетевые решения тоже влияют на задержки. На что обращает внимание Облакотека:

➡️ География. Например, мы объединили два московских ЦОД в единую «облачную фабрику» с помощью скоростных оптических каналов. Это позволяет мгновенно переносить нагрузки между площадками и строить геораспределенные кластеры без ощутимого увеличения задержки.

➡️ Магистральные сети и пиринг. Мы подключены к ключевым точкам обмена трафиком (Dataline-IX, ММТС-9). Это позволяет напрямую обмениваться данными с большинством российских провайдеров, минуя посредников. Для максимальной скорости есть возможность провести L2VPN или MPLS-туннель от офиса до облака.

➡️ Выбор маршрутов и мониторинг. Мы постоянно отслеживаем задержки и потери пакетов, и если какой-то канал начинает хромать — автоматически переключаем трафик на запасные пути. А еще используем умные протоколы маршрутизации и собственные карты задержек по стране.

Но есть и проблемы, с которыми сталкиваются провайдеры.

Во-первых, огромные расстояния в России и неравномерное развитие регионов. Строить ЦОДы везде, где это нужно, экономически невыгодно. Во-вторых, ограничения на поставки современного сетевого оборудования (коммутаторы 400G, CPU). Приходится ждать появления аналогов в РФ или искать обходные пути: использовать кластеризацию и программно-определяемые сети.

Наконец, требования регуляторов к шифрованию и фильтрации трафика могут увеличивать задержки. Приходится тщательно подбирать и тестировать отечественные решения (межсетевые экраны, DPI), которые обеспечивают безопасность без серьезного падения скорости.

#дорогой_бэклог