Обновить

Все потоки

Сначала показывать
Порог рейтинга

Зачем бизнесу гибридное облако? 🤔

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

1️⃣ Disaster recovery и георезервирование 💥

Что это: основная инфраструктура работает в локальном ЦОД или частном облаке, а резервная площадка и бэкапы — в публичном. Если случается авария, трафик и нагрузки в штатном режиме переключаются в облако.

Кому подойдет: банки, финтех, e‑commerce, телеком, здравоохранение, госсектор.

Бизнес-выгода: 

  • меньше простоев и рисков потери данных;

  • не нужно строить и содержать полноценный дата‑центр;

  • план восстановления можно регулярно тестировать без остановки основного контура.

2️⃣ Пограничные вычисления (edge computing) 🛰️

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

Кому подойдет: ритейл, промышленные предприятия, транспорт, финтех.

Бизнес-выгода:

  • локальные процессы продолжают работать даже при проблемах с интернетом;

  • можно управлять ИТ-ландшафтом из единой точки;

  • меньше требований к квалификации персонала.

3️⃣ Масштабирование под пиковые нагрузки 📈

Что это: базовая нагрузка обрабатывается на собственных ресурсах или в частном облаке, а пиковая — уходит в публичное облако.

Кому подойдет: e‑commerce, медиа, финтех, страховой бизнес.

Бизнес-выгода:

  • не нужно покупать железо, а потом обслуживать простой;

  • ресурсы в облаке включаются только тогда, когда они нужны;

  • бизнес переживает пиковую нагрузку без просадок по скорости и повышения CAPEX.

4️⃣ Разработка и CI/CD в облаке 🧪

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

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

Бизнес-выгода:

  • тестовые среды поднимают и останавливают по запросу;

  • подрядчикам не нужен прямой доступ внутрь периметра;

  • релизы выходят быстрее, а критичные данные остаются в частном контуре.

5️⃣ Защита критичных данных и систем 🔐

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

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

Бизнес-выгода:

  • компания соблюдает требования по безопасности и локализации данных;

  • снижается риск утечек, штрафов и репутационных потерь;

  • публичное облако работает там, где это безопасно и экономически оправдано.

6️⃣ ИИ и ML с данными on‑premise 🤖

Что это: сырые и чувствительные данные хранятся и обрабатываются локально, а обучение моделей и часть инференса выносятся в публичное облако.

Кому подойдет: финансы, ритейл, промышленность, автоиндустрия.

Бизнес-выгода:

  • не нужно строить дорогой GPU‑кластер под нерегулярные нагрузки;

  • можно быстро запускать и останавливать ML-эксперименты;

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

🟩 Наши новые партнерства с компаниями «Полипластик», «Ренессанс страхование»,  «Технодинамика», «АФЛТ-Системс», «LADA Цифра» и «МТ-Интеграция», которые мы заключили на ЦИПР‑2026, как раз про такие сценарии: компании из промышленности, автоиндустрии и аэрокосмической отрасли хотят запускать ИИ‑продукты, масштабироваться под пиковую нагрузку и при этом не выносить критичные данные из своих контуров. 

Для этих задач мы развиваем гибридную архитектуру Cloud.ru Evolution Stack — как основу для проектов, где публичное облако и собственная инфраструктура работают вместе, на одной кодовой базе.

Больше про гибридное облако можно почитать в нашем исследовании: про развитие гибрида в России, на Западе и в Азии. 🧠

Получить исследование ⇒

Теги:
+1
Комментарии0

Если банки не откроют данные для ИИ-агентов, они останутся витриной за стеклом

Об этом в рамках панельной дискуссии сессии «Как оседлать волну» на форуме AI Future Forum (Москва, Крокус Экспо) заявил директор по внедрению искусственного интеллекта и эффективности процессов ОТП Банка Дмитрий Маркосьянц. Модератором сессии выступила Марианна Данилина, руководитель Управления стратегии, исследований и аналитики Ассоциации ФинТех.

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

«Традиционно кредитные организации строили модель вокруг закрытого контура, где клиент получает все финансовые сервисы внутри одного банка. В то время как маркетплейсы изначально создавались иначе: часть сервисов продавцы получают от стартапов, которые существуют внутри экосистемы и обмениваются данными через открытые API. Поэтому для них тема с раскрытием данных не так чувствительна, как для банков», — пояснил Дмитрий Маркосьянц.

Также сдерживающим фактором для работы через Open API является вопрос стоимости и механика доступа, добавил спикер.

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

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

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

Отвечая на вопрос о том, нужно ли принуждать банки к открытости через регулятора, эксперт предложил альтернативный путь: «Мне кажется, надо не банки заставлять, а показать пример, когда государственные сервисы в первую очередь станут открытыми и предоставят свои возможности для банков».

Теги:
0
Комментарии2

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

Google потратил два года на исследование Project Aristotle — что делает команды эффективными. Изучили состав, навыки, опыт, структуру. И обнаружили, что фактор номер один — не кто в команде, а как люди себя в ней чувствуют. Психологическая безопасность оказалась важнее всего остального.

Это не мягкость. Это инфраструктура результата.

Команды с высокой психологической безопасностью на 35% продуктивнее, на 50% активнее делятся идеями и на 31% чаще показывают высокую производительность. При этом каждый четвёртый сотрудник до сих пор не чувствует себя безопасно, чтобы высказаться на работе.

Что разрушает безопасность?

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

По данным CCL 2026, отсутствие психологической безопасности — одна из главных причин, почему высокопотенциальные сотрудники уходят. Не зарплата. Не карьерный потолок. Среда, в которой они не могут говорить правду.

Что с этим делать руководителю?

Одна практика, которая меняет динамику быстро: моделировать любопытство вместо осуждения. На встречах — задавать вопросы, а не давать решения. «Что ты думаешь об этом?» вместо «вот как надо сделать». Звучит просто. Но именно это сигнализирует команде: здесь безопасно думать вслух.

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

Теги:
+1
Комментарии0

ИИ фри пост. Весь habr и linkedin стал пестрить людьми с AI в должности. Почти каждый стал AI Product Manager, даже если просто использует ChatGPT с дипресерчем и 1 функция вызывает Gemini Flash 2.5 по апи

Естественно начинают появляться курсы по Claude Code для продактов, вайбкодинг для нетехнарей и тд. Но у меня интерес не об этом. Мне любопытно видите ли вы спрос от работодателей на найм всех этих AI Inspired сотрудников? Не AI Engineer/DS/MLe/SWE для обвязки, а именно сопровождающих? Или мы наблюдаем новое переобуваение из Project Management/Agile/Product Management/Strategy/OKR (подчеркните для себя что застали).

Что вы знаете о спросе и предложении?

Теги:
+4
Комментарии0

Представлен открытый учебный проект easy-vibe для обучения вайб-кодингу.

  • курс имеет четыре уровня: от начального до создания прототипов ИИ‑продуктов, деплоя, подключения баз данных и мультиплатформенной разработки;

  • в курсе девять областей и более 80 интерактивных тем с анимациями и визуалом — от основ работы компьютера до передовых технологий ИИ;

  • база знаний постоянно пополняется параллельно развитию ИИ, промптов и подходов к разработке.

Теги:
-4
Комментарии0

Сделал два Telegram-канала с официальными новостями по Claude и Codex.

Официальные Claude Code новости: https://t.me/claude_official_news
Источник: https://claude.com/blog

Официальные новости Codex: https://t.me/codex_official_news
Источник: https://openai.com/news/?tags=codex

Теги:
-9
Комментарии0

Удивительно, но существует один фундаментальный хард скилл, очень легко измеряемый, по которому можно найти довольно-таки неплохих программистов, и позволяющий получать опыт программирования в несколько раз быстрее, и этот скилл никого на интервью обычно не волнует. Представьте проходит один год, а вы получаете опыта как за 2, или за 3, а если за 5? Звучит как скам, но на самом деле всё просто - это скорость набора кода руками.

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

Если ваше тело вот совсем не успевает за вашей мыслью, достичь "состояния потока"/zone легко уже не получится, скорее даже состояние потока в таком случае - это исключение из правила. Кстати, понаблюдайте за количеством минусов и плюсов к этому посту от других пользователей, наглядно показывает состояние айти сегодня. Cannot flee, the enemy can teleport behind you

Теги:
0
Комментарии6

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

Когда-то мы стали по-другому смотреть на мышцы пресса.

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

Хотя роль скручиваний при этом не отменяется.

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

Но есть у этой мышцы несколько интересных особенностей.

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

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

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

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

Теги:
+5
Комментарии2

Почему важно разбирать технический долг вовремя

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

В контексте SAST/DAST/SCA техдолг – это разница между тем, что инструмент нашел, и тем, что AppSec-инженер разобрал, а разработчик исправил. Из-за большого количества срабатываний аппсеки могут потерять реальные уязвимости.

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

Как рассчитывается

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

Почему нужно разбирать технический долг вовремя?

Спросили у инженера по информационной безопасности Swordfish Security Дениса Данилова, который помогает заказчикам разбирать технический долг в реальных проектах:

Очень часто после внедрения инструмента и первого сканирования проекта находится очень много срабатываний, на которые команда не может выделить время. Даже если аппсек разобрал все уязвимости и принёс только актуальные, разработчики сопротивляются и не хотят тратить на это время. В итоге уязвимости накапливаются и одна из них обязательно выливается в инцидент, который разработчики вынуждены чинить уже не планово, а с горящими сроками. Если же каждый спринт разбирать и исправлять хотя бы по одну уязвимость, внедрив это в процесс, разработчики не только сократят существующий техдолг, но и со временем придут к тому, что его появление значительно уменьшится. А появление нового техдолга будет ограничено механизмом Quality Gate.

💡 Советы эксперта:

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

  • Контролируйте и закрывайте временные доступы после использования.

  • Проводите инвентаризацию сервисов и API.

  • Рассматривайте технический долг как часть модели угроз.

Теги:
+1
Комментарии0

Седьмая локация для облачных серверов

Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.

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

Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.

Уже доступно в панели, проверяйте →

Теги:
+15
Комментарии0

Пароли Агентства по кибербезопасности США утекли в открытый доступ из-за подрядчика

 — Подрядчик Агентства по кибербезопасности и безопасности инфраструктуры США (CISA) до недавнего времени хранил в публичном репозитории GitHub учетные данные для доступа к внутренним системам ведомства, включая облачные ключи, токены и пароли в открытом виде

 ❗️ Исследователи в области кибербезопасности назвали инцидент одной из самых серьезных утечек данных в истории государственных структур США

В репозитории с названием Private-CISA находились административные данные для нескольких аккаунтов AWS GovCloud, а также файлы с именами пользователей и паролями от внутренних систем агентства

Эксперты также обнаружили, что владелец аккаунта отключил встроенную функцию GitHub, которая предотвращает публикацию секретных ключей и учетных данных

Этичный хакер

Теги:
+2
Комментарии0

Artemis или Kafka? Как перестать выбирать и начать использовать

Архитекторы и ИТ-директора стоят перед сложным выбором: «сверхбыстрый» ActiveMQ Artemis для транзакционных сценариев с низкими задержками или горизонтально-масштабируемая Apache Kafka для потоковой аналитики и долгосрочного хранения событий. Это была ложная дилемма.

На вебинаре 22 мая в 14:00 (мск) разберем, почему Artemis и Kafka – не конкуренты, а идеальные партнеры, и покажем, как платформа Digital Q. Integration решает задачу маршрутизации «одним окном».

Вебинар компании "Диасофт"
Вебинар компании "Диасофт"

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

Программа вебинара:

14:00 – 14:05 Ложная дилемма выбора: почему Artemis и Kafka – не конкуренты, а партнеры

14:05 – 14:15 Две философии: почта vs лента событий. Как понять, какой инструмент под вашу задачу

14:15 – 14:25 Живые сценарии. Где критична скорость, а где – история данных

14:25 – 14:40 Решение: маршрутизация через Digital Q.Integration. Как один параметр brokerType заменяет две инфраструктуры

14:40 – 14:45 Чек-лист для принятия решения при выборе интеграционной платформы

14:45 – 15:00 Вопросы и ответы

Вебинар будет интересен:

  • техническим директорам, СТО, архитекторам;

  • руководителям разработки, тим-лидам, владельцам цифровых продуктов;

  • тем, кто проектирует и поддерживает асинхронные системы обмена данными.   ·       

 Зарегистрироваться на мероприятие

Теги:
0
Комментарии0

🖥 Создатель C++ разнёс вайбкодинг: “сеньоры не хотят разгребать этот мусор”

Бьёрн Страуструп, легендарный создатель C++, в новом двухчасовом интервью резко прошёлся по вайбкодингу.

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

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

Похожая история уже достала и Линуса Торвальдса. Его буквально завалили кривыми AI-отчётами по ядру Linux: вроде бы люди “помогают”, а на практике создают шум, который мешает настоящей разработке.

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

Сеньоры не боятся ИИ.

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

Полное интервью нашел в тг тут: https://t.me/cpluspluc/1451

Теги:
+23
Комментарии9

Ближайшие события

Чистый PDF для Zotero

Записал короткое видео про свой небольшой инструмент, который помогает превращать интернет-статьи в аккуратные PDF и массово прикреплять их к источникам в Zotero.

Мне этот инструмент понадобился, так как я полюбил читать с планшета. Но в мобильном Zotero по сути только PDF хорошо работает и нормально поддерживает аннотации.

Под капотом это работает следующим образом.

Страница скачивается по URL, Defuddle от Kepano вытаскивает из неё основное содержимое без меню, рекламы и прочего мусора, а далее Playwright рендерит это в нормальный PDF.

Теги:
+1
Комментарии1

Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps и лучших примеров вабкодинга.

Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и что должно получиться на практике после каждого этапа.

Roadmap разбит на 7 треков:

  1. Фундамент: Python, математика, статистика, инструменты

  2. Классический ML: scikit-learn, табличные данные, метрики, валидация

  3. Deep Learning: PyTorch, CNN, RNN, training loop

  4. LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты

  5. Generative AI: изображения, видео, аудио, мультимодальность

  6. MLOps и прод: Docker, Kubernetes, CI/CD, monitoring, serving

  7. Специализация: CV, NLP, RecSys, RL, Safety

Roadmap не продаёт иллюзию “обучил модель - стал ML-инженером”.

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

Хорошая мысль из roadmap: LLM не делает джуна сеньором. Она ускоряет того, кто уже понимает базу. Без базы человек просто становится оператором Copilot, который не может объяснить, почему всё сломалось.

По времени тоже без сказок:

  1. 0-3 месяца: Python, математика, классический ML

  2. 3-6 месяцев: Deep Learning и PyTorch

  3. 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты

  4. 12+ месяцев: MLOps, прод, масштабирование, специализация

Тут же собрано 7 болших бесплатных курсов по машинному обучению, математике и вайбкодингу!

Если давно хотели зайти в ML системно, а не прыгать между роликами про ChatGPT, Stable Diffusion и “топ-10 библиотек”, это хороший ориентир.

https://github.com/justxor/MachineLearningRoadmap

Теги:
+3
Комментарии0

📡 Точное позиционирование как новая функция космической индустрии

Мы совсем не про GPS. Космическая индустрия стремительно развивается и предлагает для ИТ новые услуги. Starlink популяризировал быструю спутниковую связь и потряс мир (и конкурентов) 10 000 аппаратами на орбите. Но Iridium не собирается сдаваться и анонсировал решение Project Authentic, которое сочетает защищённые точное позиционирование, навигацию и точные сигналы времени — PNT.

Спутники глобальных навигационных систем — такие как ГЛОНАСС и GPS — работают на средней околоземной орбите — на высоте порядка 20 000 км. Это накладывает ограничения на точность определения координат и безопасность. Они поддаются спуфингу (выдаче пользователям в определённой локации ложного местоположения), а если сигнал зашифрован и его нельзя подделать, то его сравнительно легко заглушить.

Космические аппараты на низкой околоземной орбите (до 2000 км) имеют меньшую задержку и часто могут выдавать более высокую мощность сигнала. При точном учёте их положения и минимальном апгрейде начинки низкоорбитальные группировки позволяют более точно определять местоположение и передавать сигналы точного времени.

Iridium купила компанию Satelles и доработала её инструмент для работы с наземной инфраструктурой, который позволяет шифровать сигнал и аутентифицировать пользователя. В результате Iridium разрабатывает решение, которое позволит определять точные координаты и получать точные сигналы времени только авторизованным пользователям. Эти сигналы будет сложнее заглушить и нереально заспуфить (за счёт шифрования). Спутниковый оператор считает, что оно будет востребовано у тех клиентов, которые не могут позволить себе атомные часы, но требуют более надёжных решений, чем GPS. В частности, это могут быть операторы ЦОДов, которые используют сигналы точного времени, например, для шифрования (смена кодов происходит в строго определённый промежуток времени).

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

Теги:
+25
Комментарии0

Стартап Cheffy выпустил робота по имени E.G.O.R. (Egg, Go, On, Robot), который умеет жарить яичницу 7 разными способами. Просто закидываем яйца в специальный отсек, выбираем тип яичницы и время, к которому хотите получить завтрак — робот сделает всё далее сам.

Теги:
+5
Комментарии6

Как отключить звуковое уведомление для SMS которые рассылает RSCHS (МЧС)

Я не знаю как отписаться от рассылки SMS которые шлёт RSCHS.

RSCHS давно шлёт мне уведомления о разнообразных стихийных бедствиях, хотя я не просил его об этом, и не давал согласия включать меня в эту рассылку. Раньше я эту рассылку терпел, потому что она не была такой частой и назойливой. Но в последнее время RSCHS, душка такая, решил, что совершенно необходимо в два часа ночи сообщить мне о беспилотной опасности. Причём на каждую из моих SIM карт. А звук на входящие SMS у меня громкий. Беспилотники летают почти каждую ночь. Отключать смартфоны на ночь я не хочу. И вот здесь моё терпение лопнуло, и я стал искать способ решить эту проблему. Если у Вас на смартфоне нет возможности занести RSCHS в спам-лист, то есть другой способ.

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

Для Android. На смартфоне открываем сообщения от RSCHS, выбираем любое, тапаем по нему коротко, открывается окно Message details, или нажать длинно на сообщении - View details. В открывшемся окне в поле Service Center номер +7 921 6000088. Возможно для Вашего сотового оператора и региона номер будет другим. Создаём новый контакт «RSCHS Service Center», в поле mobile number указываем +7 921 6000088. Сохраняем этот новый контакт. Назначаем для этого контакта звук тишины - Set ringtone выбрать рингтон None.

Если на смартфоне по какой-то причине нет рингтона None. Надо создать файл mp3 содержащий тишину. Можно засунуть смартфон микрофоном под подушку и запустить на нём стандартное приложение Sound Recorder. Я использовал звуковой редактор - Audacity. Он умеет Generate Silence. На выходе получился файл silence.mp3 размером один килобайт, содержащий тишину длительностью три секунды. Копируем его на смартфон, в папку со звуками, назначаем для контакта RSCHS.

Теперь SMS от RSCHS будут продолжать поступать на Ваш смартфон, но уже молча.

Теги:
0
Комментарии9

Брать ключевую задачу для ИИ-автоматизации?

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

Подход вроде логичный, ведь core-задача компании обычно — это то, на что тратится большая часть времени, так ведь?

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

Закон больших компаний гласит: 40% времени пожирают рутина и бюрократия. Но ведь остаются 60% для реальной работы? 

А вот нет, потому что человеческая психика воспринимает всё по-другому, и сходить на созвон на час не означает, что выпал только час. 

Иначе говоря, когда вы потратили 40% своего времени на рутину, вы потратите ещё 40% на переключение между рутиной и реальными задачами (чтобы вернуть себе фокус внимания) и чтобы просто восстановиться. 

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

Банально забронировать себе отпуск в некоторых компаниях может означать не нажатие одной кнопки, а контакты с 3–5 людьми, погоню за ними и волны волнений.

Что все это значит для автоматизации именно через ИИ? ИИ — это первый вид автоматизации, который условно может все. Раньше, если есть тул для автоматизации тестирования, то, по сути, только ее и то с определенными ограничениями он и может делать. А вот ИИ может делать очень разные задачи.

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

Больше по теме тут.

Теги:
0
Комментарии0

Puppet 8 for DevOps Engineers — книга, после которой лучше понимаешь инструмент

Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.

И книга оказалась просто 10 из 10.

Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.

Что внутри:

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

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

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

Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.

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

По итогу:

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

Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.

Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.

Теги:
+1
Комментарии0