Привет, %username%!

Мы — команда разработчиков платформы для управления облачной ИТ-инфраструктурой Cloudlink.

💼10+ организаций используют наше решение

👨🏻‍💻1000+ довольных пользователей

💻300+ серверов под управлением в трех ЦОД

🏅 50+ платформенных и инфраструктурных сервисов

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

Всё про облака и сервисы, разработку и эксплуатацию, инфраструктуру и поддержку, продажи и менеджмент, и не только.

Подпишись, чтобы не пропустить!

Больше информации на сайте cloudlink.ru

#облако #cloud #cloudlink #cmp #виртуализация #iaas #paas

Разобщенность целей смежных команд.
Поговорим о взаимодействии команд разработки и эксплуатации, а также рассмотрим DevOps как вариант достижения консенсуса.

Так исторически сложилось

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

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

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

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

Плюсы и минусы

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

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

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

Взболтать, а не смешивать

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

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

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

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

#engineering #development #management

🚀 Маленькая, но важная частичка инфраструктуры для работы кластеров. ⏰

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

🔧 Сейчас мы находимся в процессе разработки продукта Kubernetes,
который можно будет получить буквально парами кликов мышки.
И для построения мульти мастера критически важно синхронизированное время между нодами.
Оно гарантирует, что все внутренние события и логи являются консистентными,
что в свою очередь помогает избежать ошибок и конфликтов, связанных со смещенным временем (aka split-brain).

🔒 Также, синхронизированное время позволяет корректным образом создавать TLS-сертификаты,
которые необходимы для безопасной коммуникации между компонентами кластера.

#Kubernetes #инфраструктура #серверы #кластеры #разработка

Постмортем как неотъемлемая часть работы инженера

Разберемся что такое постмортем и как отделять мух от котлет работу от текучки


Инженерная работа vs операционная текучка

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

Хорошо, когда инженер тратит не более 50% своего времени на обработку запросов на обслуживание и сопровождение внедрений. В таком случае, остальное время используется для работы над проектами. А проекты — это отличный плацдарм для прокачивания своих hard skills.
Этого показателя можно достичь на практике путем наблюдения за количеством операционной работы, выполняемой командой инженеров. Все, что выходит за рамки 50% — перенаправлять на команды разработки заранее согласованным и утвержденным маршрутом для последующей автоматизации, желательно без ручного участия. Этот способ обеспечивает эффективную обратную связь, ориентируя разработчиков на создание систем, не требующих человеческого вмешательства. Чтобы такой подход работал, все команды внутри компании должны понимать почему это ограничение существует.

Постмортем

Опираясь на опыт работы наших самых больших коллег, оптимальное число критических событий для обработки не должно достигать более трех за 8-часовую смену на дежурстве. В таком случае, инженеру точно удастся обработать событие и восстановить сервис, а затем проанализировать первопричину произошедшего. Если событий больше чем три, то у инженеров не получится предотвратить аналогичные ошибки в будущем.
Стоит обратить внимание на то, что если инженер стабильно получает меньше критических событий за дежурство, то нельзя считать его работу на месте дежурного пустой тратой времени. Есть легенда, что в крупных зарубежных компаниях инженерам, отвечающим за стабильность сервисов, платят щедрые бонусы, когда все сервисы в зоне их ответственности показывают пресловутые «пять девяток» доступности (если это не так, то дайте знать).

Отчет с анализом причин произошедшего (в простонародье «постмортем») необходимо писать для всех значимых инцидентов, независимо от того сопровождались ли они уведомлениями или нет. Более того, постмортемы для событий без уведомления представляют больше ценности, так как они указывают на недостаточность мероприятий по мониторингу.
Группа, отвечающая за расследование инцидента, должна установить все детали случившегося, найти все первоначальные причины проблемы и выработать план минимизации возникновения подобных случаев, а также поспособствовать улучшению способа обработки такого события.

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

#engineering #sre #management

Бюджет ошибок и его влияние на качество внедрений

Разберем понятие суммарного уровня ошибок и попытаемся достичь максимальной скорости внедрения без изменений качества обслуживания.

Суммарный уровень или error budget

Противоречия между командами разработчиков и инженеров заключается в соотношении темпов внедрения изменений и стабильности продукта.
Мы должны приложить все усилия, чтобы вывести этот конфликт на первый план, а затем постепенно избавляться от него, вводя понятие суммарного уровня ошибок, или бюджета ошибок (error budget).
Это значит что достижение 100%-ной надежности будет необоснованным требованием в подавляющем большинстве случаев. Посудите сами: для любой* системы 100 % — избыточный показатель надежности, поскольку ни один пользователь не заметит разницу между 100% и 99,999%, так как она теряется на фоне случайных факторов, обусловленных недоступностью других систем (wi-fi, ноутбук и т.д.).
Прежде чем начать размышления на тему стремления к 100% уровню надежности, то задайте сами себе следующие вопросы:
• ‰Есть ли у недовольных доступностью пользователей какие-либо альтернативы?
• ‰‰Как на них отразится изменение уровня доступности продукта?
• ‰Какой показатель доступности удовлетворит пользователей, при условии, что мы знаем как и когда они используют продукт?

Нужно ли стремиться к «сотне» и переживать из-за багов?

Коротко: в подавляющем большинстве случаев — нет*.
Система должна иметь установленный целевой показатель доступности.
Как только этот показатель будет определен, также будет определен допустимый суммарный уровень ошибок, который будет равен единице минус запланированный показатель доступности.
Например: доступный в 99,99 % случаев сервис будет недоступен в 0,01 % случаев. 0.01% — ни что иное как бюджет ошибок.
Участники команд вольны тратить этот «бюджет» на все, что хотят, но лучше тратить на что-то полезное (спасибо, кэп🫡).
Однако если бюджет ошибок потрачен или понижен (т.е. сервис работает на уровне, определенном в SLA или ниже его), то запуск любых новых возможностей замораживается до тех пор, пока команда не уменьшит количество ошибок до уровня, позволяющего продолжить запуск.

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

*если речь идет о каком-то сервисе, который подвергает риску жизни людей или большому финансовому убытку, то, безусловно, доступность должна быть 100% (например, системы поддержания жизнедеятельности и иные медицинские сервисы, автоматическая система торможения в автомобиле, системы мониторинга на ГЭС/АЭС и т.д;)


#engineering #sre #management #sla

Программирование с Ansible: Как сделать жизнь проще и немного веселее! 🚀

Бывают такие моменты, когда нужно приложить усилия, чтобы автоматизировать целую кучу компонентов в огромной системе,
и еще взаимодействовать с этими штуковинами по HTTP. Да, звучит серьезно, но давайте разберемся вместе! 🤖💬

Допустим, у нас есть проект, и нам приходится загружать файлы в Nexus.
Но ведь это не просто загрузка – нам нужно сделать это эффективно и идемпотентно. 📦🎯

Скажем, у нас есть список задач:
1. Рассчитать MD5-сумму файла.
2. Обратиться к Nexus и узнать, есть ли там такой файл.
3. Сравнить MD5-суммы файлов.
4. Решить, стоит ли загружать файл или уже есть такой. 🤔

На первый взгляд, всего лишь четыре пункта, но в реальности это может вылиться в кучу строчек кода в нашей Ansible-роли.
И вдобавок, если нужно как-то обрабатывать данные, то сложность только возрастает. 📜🔍

Но не переживайте, выход есть, и он называется Ansible action plugins либо же modules.
В чем разница? Modules работают на сервере, а action plugins – на вашей рабочей машине. 🖥️🔧

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

Плюс в том, что мы работаем с полноценным языком программирования – Python, и можем использовать все его фишки.
Таким образом, можно значительно упростить нашу Ansible-роль, свести четыре задачи к одной. Волшебство! 🪄✨

#Ansible #ActionPlugins #Автоматизация #Python #Программирование

Кастомизация виртуальных машин пользовательскими shell скриптами

Развертывание виртуальной машины - это довольно трудоемкий процесс, который требует ручной установки и настройки пакетов, необходимых для запуска ваших приложений. Но эту задачу можно выполнить намного проще и быстрее! Cloudlink берет на себя все заботы по настройке и установке необходимых пакетов, используя готовые шаблоны, которые были подготовлены нашими разработчиками.

Недавно один из наших клиентов задал нам вопрос: "А что, если я хочу запускать свои shell-скрипты на вновь созданных виртуальных машинах?" Мы изучили вопрос и нашли несколько решений на эту проблему.

В большинстве платформ виртуализации и публичных облачных сервисов есть функциональность, позволяющая пользователю передавать свои скрипты на стадии преконфигурации. И казалось бы это то что нужно - использовать специально отведенное для таких задач поле. Однако выяснилось что каждая платформа имеет свои ограничения, например, размер параметра user_data в vSphere 7 не может превышать 3 кБ. Как же быть, если скрипты имеют больший размер?

Мы нашли вариант, который поможет решить эту проблему - использование встроенного ansible.builtin.shell модуля. Он позволяет выполнять любые консольные команды и применять на виртуальной машине shell-скрипты любого размера. Таким образом мы унифицируем все эти действия между разными платформами.

Сейчас эта опция уже находится в разработке и скоро будет выпущена в релиз!
Сталкивались ли с такой задачей? Как вам ее удалось решить?

#Автоматизация #shell #Ansible

Долгожданная новость ✨💫
Выпущен 64 релиз Cloudlink

Что нового?

Технические изменения:

1. Изменения в Order Service. Опции для настройки Дата-Центров, Платформ, Доменов и Сегментов сети административной панели перенесли в основное меню Control Panel. Это позволит проще настраивать инфраструктуру через UI 🤗
2. BugFix 🛠️. Решили проблему периодического конфликта разведки и деплоя виртуальных машин на платформе vSphere


Общие изменения:

1. По вашим заявкам добавили окно подтверждения выхода из портала самообслуживания 👍
2. Небольшие изменения в интерфейсе:
- дополнительные проверки корректности вводимых полей на странице создания организации

-фиксированное применение светлой темы

-корректирование имен фильтров в разделе IAM и Управление

Аналитика:

1. В карточках появилась возможность экспорта во внешние ресурсы 📈
это поможет нашим клиентам упростить интеграции с учетными системами 🔥 (например, с 1С 😉)


Продуктовый маркетплейс:

1. Добавили поддержку новой гостевой ОС AlmaLinux и тиражировали всю продуктовую линейку для этой ОС 🤩

2. Добавили новый продукт K8S 🥂🍾. Умеем создавать кластеры с различным количеством рабочих узлов и управлять ими (стоп/старт/ресайз) на всех поддерживаемых платформах (если вдруг забыли, мы работаем с vSphere, zVirt, Openstack)

Ставь лайк, если понравились фичи в новом релизе 👍

Кстати, мы открыли комментарии!
Самое время написать туда что бы вы хотели увидеть в следующем релизе 😊

#release_note #k8s #almalinux #iaas #paas #cloud

Мониторинг и реагирование на критические ситуации

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

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

Категоризация событий

Существует три категории данных от системы мониторинга:

‰‰1. Срочные оповещения (alerts) — указывают, что нужно немедленно реагировать на что-то, что либо уже произошло, либо вот-вот произойдет.
2. Запросы на действия (tickets) — указывают на то, что система не может обработать событие автоматически, но предпринимать какие-то действия можно не сразу.
‰‰3. Журналирование (logging) — полезные для диагностических целей артефакты.

f(MTTF, MTTR) = Надежность

Надежность - это функция от MTTF и MTTR

Mean time to failure, MTTF — среднее время безотказной работы
Mean time to repair, MTTR — среднее время восстановления, самый значимый критерий оценки эффективности реагирования на критические ситуации.

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

Какой системой мониторинга пользуетесь вы? Довольны ли выбором системы оповещений?

#мониторинг #engineering #sre #надежность #alerts

Всех с пятницей! 🚀

Желаем хорошо провести эти выходные и набраться сил!

На следующей неделе поговорим про:
• Мониторинг распределенных систем — как наблюдать за большим приложением и при этом ничего не упустить
• Выбор подходящего уровня детализации для измерений показателей — как не положить сервис избыточными запросами
• Эволюция автоматизации — зачем нужно перекладывать рутину на автоматизацию и как Cloudlink может помочь с этим
• Поделимся запланированными новыми фичами нашего продукта
До встречи!

Эффективная работа с архивами Docker образов 🐳

Иногда возникает необходимость перенести Docker образ в закрытый контур и импортировать его в какое-либо хранилище.
И мы хотим сделать это как можно эффективнее, с точки зрения размера файла и времени импорта.
Как раз с такой задачей мы столкнулись на нашем проекте при развертывании Cloudlink. ☁️

В чем собственно проблема? 🤔
У нас есть порядка 70 образов, которые необходимо доставить на сервер, так называемым air-gap способом, чтобы обеспечить установку в полностью закрытых контурах, без интернета.

Как обеспечить скорость импорта, а так же сохранить относительно небольшой размер файла? 📏
Мы попробовали несколько решений, и теперь хотим ими с вами поделиться.

Способ №1 - docker save 📚
Если мы используем Docker, то кажется что самый простой вариант - это воспользоваться стандартной командой:

docker save python:3.11-slim > python-3.11.tar

В результате мы получили tar архив, в нем присутствуют метаданные и слои, но они находятся в не сжатом виде, поэтому размер файла достаточно большой (в случае с нашим образом получилось 149M). 😱

Хорошо, мы можем его сжать, используя gzip: 🗜️

docker save python:3.11-slim | gzip -c > python-3.11.tar.gz

Уже неплохо, размер файла значительно уменьшился (теперь 50M). 😌
По итогу получилось что метаданные и слои сжаты.

Если мы хотим каким-то образом работать с метаданными, которые находятся в архиве, то сначала придется разархивировать файл.

time tar -xzf python-3.11.tar.gz manifest.json

0.38s user 0.01s system 99% cpu 0.393 total

Кажется что 0.393 секунд это не много, но если мы работаем с большими образами (> 1GB), то разархивирование может занимать до нескольких секунд на один файл ⏳

Способ №2 - skopeo 🛠️
Следующий способ который мы попробовали - это использование skopeo:

skopeo copy docker://python:3.11-slim docker-archive:python-3.11.tar

К сожалению такой способ нам так же не совсем подходит, так как на выходе получается не сжатый tar файл (149M). 😞
Так же мы столкнулись с трудностями установки skopeo на относительно старые дистрибутивы, например Ubuntu 20.04 🐧, где нужно собирать пакет из исходников, что добавляет трудностей в поставке на полностью закрытые контура, air-gap методом.

Способ №3 - crane 🏗️
Далее мы решили попробовать crane:

crane pull python:3.11-slim python-3.11.tar

Кажется что он так же делает простой tar файл, но как оказалось не совсем. 🧐
Во-первых, мы сразу видим что его размер 51M. 👍
Если заглянуть внутрь, то мы увидим что слои внутри сжаты, но при этом метаданные нет:

tar -tf python-3.11.tar

sha256:596e0d6b34dfaa7ed330941075bcd38b376b3eba8e5b63a1da38bf04fe08bdd3
52d2b7f179e32b4cbd579ee3c4958027988f9a8274850ab0c7c24661e3adaac5.tar.gz
2b8a9a2240c1224b34f6aafbc3310f9a3fe65bd6893050906d02e89fc8326aa9.tar.gz
051d6521462a7eb4ca0374e97701d6eec68eb51b118d3ef5d002798b498fb12e.tar.gz
fce84b1f897c621e9474bd4d5a49e2e22fa35e248e78e754010d34ec3d2d28cd.tar.gz
46233543d8c2dc599bdb9d522180ca9e14cad4ac2017a5dc481660bfa4aa3ed9.tar.gz
manifest.json

Таким образом мы можем очень быстро эти метаданные читать, при этом не сильно теряя в размере файла. 🚀

time tar -xzf python-3.11.tar manifest.json

0.00s user 0.00s system 65% cpu 0.005 total

Итоги 🫶
Мы решили остановиться на crane, так как он полностью покрывает нужную нам функциональность и делает скачивание/загрузку образов простой и эффективной.

Надеюсь, что наш пост был полезным для вас и вы нашли что-то новое и интересное. 😊

#docker #crane #skopeo #devops #dockerimages

Прогнозирование нагрузки и планирование производительности

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

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

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

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

Материальное обеспечение

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

Производительность и эффективность

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

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

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

#capacity #engineering #computing

🔥Cloudlink включен в реестр отечественного ПО 🔥


Вчера пришла отличная новость, что Cloudlink включен в реестр отечественного ПО
Реестровая запись №18665 от 22.08.2023

Программы, зарегистрированные в реестре российского ПО, могут распространяться под 0% НДС (п.26 ст.149 НК РФ) на основании:

‰ • лицензионных договоров;
‰ • договоров на отчуждение исключительных прав на ПО;
‰ • продажу экземпляров ПО.

Льготой могут пользоваться не только разработчики и правообладатели, но и все участники цепочки поставки программного обеспечения — компании, которые продают, устанавливают и поддерживают Cloudlink.

Ждем ваши огонечки 🔥и принимаем поздравления в комментариях 🤗👇

Ура-а-а!!!

#cloudlink #реестр_отечественного_по