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

Данные: кандидаты не против AI — они против того, как его применяют

Начнём с масштаба. По данным SHRM Talent Trends 2025, доля AI в HR-процессах за год почти удвоилась — с 26% до 43% рабочих сценариев. Это говорит о том, что AI в найме больше не эксперимент, а новая норма.

Проблема в том, что кандидатский опыт за этой скоростью не поспевает. Свежий отчёт Greenhouse 2026 Candidate AI Interview Report (опрошено 2 950 активных соискателей в пяти странах) рисует довольно мрачную картину:

• 63% кандидатов проходили AI-интервью за последний год — рост на 13% всего за полгода;
• 38% уже снимались с процесса найма именно из-за AI-интервью, ещё 12% готовы уйти, если их обяжут его проходить;
• 51% из тех, кто всё-таки прошёл AI-интервью, не получили никакого результата — их либо проигнорировали, либо они всё ещё ждут ответа;
• 34% после AI-интервью стали хуже относиться к компании;
• 70% вообще не предупредили заранее, что их будет оценивать AI.

Отдельно стоит гостинг (ghosting) — внезапное молчание компании, когда кандидату просто перестают отвечать. По данным, которые приводит Fortune, в 2026 году с ним столкнулись 53% соискателей, это трёхлетний максимум (против 48% в 2025 и 38% в 2024). И связывают этот рост напрямую с AI: инструменты позволяют кандидатам рассылать отклики пачками, рекрутеров заваливает и они просто не отвечают тем, кому отказ пришёл автоматически. Классическая петля обратной связи: чем больше автооткликов, тем больше автоотказов.

Мы решили проверить это на своей аудитории

Чтобы не опираться только на публичные отчёты, мы провели два анонимных опроса в наших Telegram-каналах: один про главную боль в AI-найме (2 633 голоса), второй — про влияние на отношение к компании (2 273 голоса).

Результаты близки к мировыми. Раздражает хотя бы что-то в AI-найме 90,7% опрошенных — вариант «меня это не раздражает» выбрали лишь 9,3%. Две главные боли идут вровень: невозможно достучаться до живого человека (30,4%) и шаблонный отказ без объяснения причин (30,2%). То есть сильнее всего бьёт не сама технология, а дегуманизация — ощущение, что тебя обрабатывает конвейер, а не рассматривает человек.

И, что важнее, это конвертируется в ущерб бренду. Отношение к компании после плохого AI-опыта меняется у 82,4% (не меняется только у 17,6%). А 22,2% готовы активно отговаривать знакомых от взаимодействия с такой компанией. Почти каждый четвёртый кандидат превращается в канал антирекламы.

Ключевой вывод из всех цифр один, и его хорошо сформулировали в Greenhouse: только 19% кандидатов хотят меньше AI в найме. Люди не против автоматизации — они против того, как её внедряют: без предупреждения, без объяснений и без возможности достучаться до человека.

Как компания «переAIивается»

Чтобы показать, как это выглядит в динамике, соберём обобщённый сценарий. Компания «Хоризон» — вымышленная, но ни один поворот в её истории не выдуман: за каждым стоит реальный публичный прецедент.

Эйфория. Поток откликов вырос в разы, рекрутеры тонут, «Хоризон» покупает систему автоскрининга. Первый год — восторг: время до шортлиста падает, стоимость найма снижается. Именно на этом успехе компании и «переAIиваются», он выглядит как повод автоматизировать всё подряд.

Скрытая предвзятость. Модель учится на резюме прошлых успешных сотрудников и начинает воспроизводить уже существующий состав команды, отсеивая «непохожих». Ровно на этом обжёгся Amazon: его инструмент, обученный на резюме за десять лет, научился предпочитать мужчин и задвигать резюме со словом «женский». Сделать модель нейтральной не удалось — проект тихо закрыли. Никто не писал правило «отсеивать женщин». Просто система скопировала человеческую предвзятость и автоматизировала её.

Автоотказы приводят к судебному иску. Чтобы разгрузить рекрутеров, «Хоризон» включает критерии автоматического отказа. Так поступила iTutorGroup: её софт автоматически отклонял женщин от 55 лет и мужчин от 60, отсеяв больше 200 квалифицированных кандидатов. Вскрылось случайно: кандидатка подала две одинаковые анкеты, отличавшиеся только датой рождения, и приглашение на собеседование получила только с более «молодой» версией резюме. Итог — 365 000 долларов по мировому соглашению с EEOC, первому в истории по AI-дискриминации в найме. И урок для каждого HR-отдела: даже когда дискриминацию автоматизирует технология, ответственность всё равно несёт работодатель.

Doom loop и системный риск. Опыт кандидата иногда схлопывается ещё до конвейера. Как в деле против Workday: истец подал больше сотни заявок через платформу и получил отказы по всем, причём часто в течение минут, иногда посреди ночи. Так он заподозрил, что решение принимала машина. В мае 2025 суд разрешил вести иск как коллективный, от лица потенциально сотен миллионов соискателей, а по собственным данным компании за спорный период через её инструменты было отклонено 1,1 млрд заявок. Workday обвинения отрицает и настаивает, что её инструменты не принимают решений о найме, но в июне 2026 суд в Калифорнии позволил части претензий двигаться дальше. Суть здесь в том, что ответственность может лечь и на вендора, а не только на конкретного работодателя.

Где «Хоризон» теряет не деньги, а бренд. Кандидаты, отсеянные «за секунды в два часа ночи», редко идут в суд — они пишут отзывы и предупреждают знакомых. Это ровно то, что показал наш опрос: 82,4% меняют отношение к компании, 22,2% отговаривают других. Юридический иск довольно редкое явление, а репутационные потери — ежедневное и почти неизбежное.

Найм в «Хоризон» сломал не сам AI, а три конкретные вещи: решения без человека, отказ без объяснения причины и полное исчезновение живого контакта. По сути, компания автоматизировала не рутину, а именно те точки, где кандидат ждёт человека.

Чек-лист: где AI работает, а где вредит

Если свести все прецеденты и данные вместе, станет понятно, что граница проходит не по технологии, а по тому, ждёт ли кандидат в этой точке человека. Там, где взаимодействие и так безличное, AI должен выступать ассистентом, оптимизировать процесс. Риск начинается там, где AI перестаёт помогать человеку и начинает принимать за него решения — именно эти сценарии привели к судебным искам из кейсов выше, и 22,2% готовых к антирекламе в нашем опросе.

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

AI помогает:

• Написание и оптимизация текстов вакансий;
• Первичный парсинг и сортировка резюме — как один из сигналов, а не как решение;
• Планирование, перенос интервью, напоминания;
• Ответы на типовые вопросы о вакансии и статусе заявки;
• Черновики писем, которые редактирует человек.

AI вредит:

• Автоматический отказ без проверки живым рекрутером;
• Отказ без внятной причины;
• AI-видеоинтервью «с роботом» как единственный этап;
• Полное отсутствие человека на всём пути;
• Анализ мимики и эмоций — запрещён EU AI Act с февраля 2025 года.

Как понять, что на конкретном этапе нужен человек? Простой тест: представьте, что кандидат спросил «почему так?». Если у вас есть понятный ответ и за решением стоял человек — этап в зелёной зоне. Если ответить нечего или всё решил алгоритм — этап пора возвращать людям.

Фреймворк «Human-in-the-loop»: алгоритм советует, человек решает

Хорошая новость: кандидаты сами подсказывают, как надо. В том же отчёте Greenhouse они называют, чего им не хватает: раскрытия факта использования AI (44%), понятного объяснения, что именно AI оценивает (39%), возможности запросить человека вместо робота (46%), гарантии, что человек проверяет оценку AI до решения (38%), и доказательств, что систему проверяли на предвзятость (29%). Это, по сути, готовое ТЗ на здоровый процесс.

Всё это складывается в один принцип: алгоритм советует — человек решает. Ни одно значимое кадровое решение (найм, отказ, повышение) не отдаётся модели единолично; её оценка — лишь один сигнал среди многих.

На практике принцип держится на трёх опорах:

• Объяснимость: вы должны уметь сказать, почему кандидат А оказался выше кандидата Б, причём сказать это самому кандидату, а не только себе;
• Аудируемость: должна быть возможность проверить, что живой рекрутер видел и подтвердил рекомендацию AI, а не проштамповал её вслепую;
• Тест на предвзятость: систему нужно регулярно проверять на демографические перекосы и другие отклонения, иначе повторится история Amazon, где модель годами воспроизводила состав команды, пока это не всплыло.

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

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

Что в итоге

AI в найме — не зло и не мода, от которой можно отмахнуться: 43% HR-процессов уже так или иначе на нём. Но данные с обеих сторон — и отчёты, и наш опрос — сходятся в одном: кандидаты уходят не от самого AI, а от плохого опыта, который создаёт неправильно выстроенный AI-процесс. У кандидатов должно оставаться ощущение, что их рассматривают, а не просто обрабатывают на конвейере.

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

Хотите провести свой опрос или разместить материал? Пишите нам.

Это не очередной корпоративный конфликт. История соединяет в себе инвестиции Amazon в Anthropic, секретную программу доступа к киберспособностям ИИ, появление южнокорейского оператора в списке участников и попытку администрации США установить новый стандарт безопасности frontier-моделей. Разбираем, как звонок одного топ-менеджера запустил цепочку, которая поставила под вопрос саму возможность коммерческого запуска сильных ИИ.

Энди Джасси сообщил о jailbreak Fable 5 на регулярном звонке с Белым домом 11 июня, хотя Amazon инвестировала в Anthropic $4 млрд и является основным облачным партнёром компании.

Министр торговли США Говард Лутник поставил Anthropic ультиматум: устранить уязвимость за 90 минут или отключить Fable 5 и Mythos 5 глобально.

Дополнительный триггер — расширение программы Project Glasswing примерно на 50 организаций без предварительного одобрения национальной безопасности, включая SK Telecom.

CEO Anthropic Дарио Амодеи отверг оба варианта решения, назвав применённый стандарт невыполнимым для любой frontier-лаборатории.

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

Что произошло: от звонка до отключения за 33 часа

11 июня Джасси участвовал в запланированном звонке с чиновниками Белого дома. Повестка была не про ИИ, но перед завершением он упомянул, что исследователи Amazon задокументировали метод обхода защит Fable 5 — модели, которую Anthropic выпустила за два дня до этого. Чиновники посоветовали ему обратиться напрямую к министру финансов Скотту Бессенту. Джасси сделал это в тот же день.

К следующему вечеру тема перекочевала из министерства финансов в министерство торговли. 12 июня в 17:21 Лутник подписал директиву Anthropic: компания получила 90 минут на решение — исправить jailbreak или вывести Fable 5 и Mythos 5 из эксплуатации. За такой срок техническое исправление было невозможно, и Anthropic отключила обе модели глобально ещё до 22:00.

Примечательно, что Джасси выбрал официальный канал, а не прямой разговор с Anthropic. Это ускорило реакцию и превратило уязвимость из внутреннего инцидента в государственное дело. Amazon отказалась комментировать роль Джасси; Anthropic — обсуждать внутреннюю хронологию.

Project Glasswing: почему список доступа оказался важнее самого jailbreak

Сам по себе jailbreak, скорее всего, не вызвал бы столь жёсткой реакции. Триггером стала вторая находка: недавнее расширение программы Project Glasswing, в рамках которой Anthropic давала избранным организациям доступ к Claude Mythos — модели с сильными киберрассуждениями, ориентированной на задачи национальной безопасности.

К началу июня Anthropic добавила в программу около 50 новых организаций без предварительного согласования с американскими чиновниками по национальной безопасности. Одной из них стала SK Telecom — крупнейший южнокорейский оператор связи. Компания опровергла любые связи с Китаем, но её появление в списке без согласования вызвало в Вашингтоне вопрос: а кто ещё получил доступ к Mythos?

Когда отчёт о jailbreak пришёл на фоне уже накопившихся подозрений, два фактора сложились. Расширение Glasswing разрушило доверие между Anthropic и национально-безопасственным истеблишментом, а уязвимость дала повод действовать немедленно. Расследование Fortune, опубликованное 18 июня, называет именно эту комбинацию ключевой в решении Белого дома.

Позиция Anthropic: почему Дарио Амодеи сказал «нет»

Ультиматум Лутника предполагал два варианта: устранить jailbreak или отключить модели. CEO Anthropic Дарио Амодеи отверг оба на принципиальной основе. Дело в том, что уязвимость связана с обычным запросом: попросить модель просмотреть код и исправить ошибки. Это легитимный и распространённый сценарий использования, а не экзотическая атака.

В публичном заявлении Anthropic назвала находку «узким, неуниверсальным jailbreak'ом», который не соответствует планке для полного коммерческого отзыва. Компания также предупредила, что если такой стандарт применить отраслево, он фактически остановит все новые релизы frontier-моделей.

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

Советник Белого дома по ИИ Дэвид Сакс сначала высказался оптимистично, назвав проблему «легко решаемой». Однако к 16 июня переговоры зашли в тупик, экспортные ограничения для иностранных пользователей оставались в силе, а Сакс действовал уже в консультативном качестве после ухода с формальной должности. 19 июня управляющий директор Anthropic по международным вопросам Крис Чаури сообщил журналистам, что модели появятся «в ближайшие дни», но точной даты не назвал.

Технический разбор: может ли frontier-модель быть безупречно защищённой?

В центре конфликта — требование, которое администрация фактически выдвинула Anthropic: гарантия отсутствия jailbreak'ов. Исследователи безопасности, опрошенные несколькими изданиями, единодушны: модель, устойчивая к jailbreak'ам на 100 %, не существует.

Невозможно гарантировать, что модель останется неуязвимой к jailbreak'ам навсегда. Тот, кто это обещает, что-то продаёт.

Аргумент Anthropic строится именно на этом. Компания не отрицает наличие уязвимости, но оспаривает стандарт. Если один узкий jailbreak в коммерческой модели оправдывает глобальный отзыв, то ни одна frontier-лаборатория не сможет выпускать продукты: каждый релиз так или иначе содержит слабые места, обнаруживаемые сообществом в течение дней или недель.

Это ставит регуляторов перед дилеммой. С одной стороны, нужен механизм реагирования на опасные уязвимости, особенно когда речь идёт о моделях с киберспособностями и секретных программах доступа. С другой — стандарт «нулевого jailbreak» технически недостижим, и его применение превратит frontier-рынок в поле для политического произвола.

Что это значит для России и остального мира

Для российских разработчиков и компаний инцидент — ещё один сигнал, что доступ к сильным зарубежным моделям может исчезнуть за часы. Экспортные ограничения после 12 июня коснулись не только российских пользователей, но и европейских, азиатских и латиноамериканских. Разница между «коммерческий API доступен» и «модель отключена» сократилась до 90 минут одного чиновника.

В России это усиливает аргументы в пользу собственных ИИ-инфраструктур и моделей: отечественные чипы, национальная облачная платформа, локальные large language models. Но копировать архитектуру недостаточно — важны процессы безопасности, аудита и прозрачного доступа. История с Glasswing показывает, что скрытое расширение списка партнёров может разрушить доверие быстрее, чем любая техническая уязвимость.

Выводы: дилемма, которую пока никто не решил

История с Fable 5 — не просто очередной конфликт ИИ-лаборатории и регулятора. Это демонстрация того, как быстро инфраструктура доступа к сильному ИИ может быть перекрыта одним политическим решением. Джасси поднял тревогу, Лутник перевёл её в ультиматум, Амодеи отказался подчиниться — и миллионы пользователей лишились доступа к двум лучшим моделям Anthropic.

Главный вопрос остаётся без ответа: какой стандарт безопасности применим к коммерческим frontier-моделям? Белый дом хочет гарантий, которых технически не существует. Anthropic хочет сохранить способность выпускать продукты, не рискуя отключением из-за каждого найденного jailbreak'а. Пока эти позиции не сойдутся, ни одна сторона не сможет объявить победу.

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

Правительство требует условия, которое Anthropic технически не может выполнить. Anthropic требует условия, которое оно не может принять, не открыв дверь для отключения любой модели по одному найденному jailbreak'у. Пока такого компромисса нет.

Источники

Основа материала — расследование Fortune о роли Энди Джасси в отключении Fable 5 и Mythos 5, опубликованное 18 июня 2026 года. Дополнительный контекст — официальные заявления Anthropic, комментарии Дэвида Сакса и оценки исследователей безопасности.

• The Inside Story of the Call That Banned Fable 5 — Awesome Agents (на основе расследования Fortune)
• Statement on the US government directive to suspend access to Fable 5 and Mythos 5 — Anthropic
• Anthropic suspends all access to Mythos model after US government bans foreign nationals use — CNN Business
• US orders Anthropic to disable AI models for all foreign nationals — Al Jazeera
• The White House Wants Anthropic to Block All Jailbreaks. That May Be Impossible — Gadget Review

Business Insider со ссылкой на двух знакомых с планами людей сообщает: Microsoft, владелец GitHub, вынуждена арендовать дополнительные вычислительные мощности у Amazon Web Services. Официальный представитель Microsoft подтвердил лишь использование нескольких облачных провайдеров, но отказался комментировать участие Amazon. AWS — главный конкурент Microsoft Azure на рынке облаков, поэтому конкуренты вынуждены сотрудничать.

• Microsoft планирует разместить часть нагрузки GitHub на Amazon Web Services из-за нехватки собственных мощностей.
• При сохранении текущего темпа число коммитов на платформе может вырасти с 1 млрд в 2025 году до 14 млрд в 2026 году.
• В 2026 году GitHub пережил десятки крупных сбоев.
• Microsoft намеревалась полностью перевести GitHub на Azure к 2027 году, но ИИ-бум ускорил потребность в дополнительных мощностях.

Что произошло

GitHub — популярная платформа для хранения и совместной работы над кодом. До поглощения Microsoft в 2018 году она в основном использовала собственные дата-центры. Корпорация планировала полностью перевести GitHub на Azure к 2027 году, но всплеск активности, связанный с разработкой на базе ИИ-агентов и ассистентов, заставил пересмотреть сроки и искать мультиоблачную схему.

Рост коммитов в 14 раз

По данным директора по операциям GitHub Кайла Дейгла, при сохранении текущего темпа число коммитов — записей об изменениях в коде — в 2026 году может достичь 14 млрд против 1 млрд в 2025. Microsoft, со своей стороны, прогнозирует общие капитальные затраты корпорации в $190 млрд в 2026 году, в основном на расширение дата-центров, но часть проектов откладывается.

Почему Microsoft идёт на сделку с AWS

Конкуренция между Azure и AWS не отменяет главную задачу — не допустить сбоев в работе сервиса. В 2026 году GitHub пережил десятки крупных сбоев. Кроме того, на рынке появляются альтернативы вроде Cursor и Claude Code, которые конкурируют с экосистемой GitHub и Copilot, и Microsoft приходится ускорять модернизацию инфраструктуры.

Конкуренция за разработчиков

GitHub больше не место для серьёзной работы, если он ежедневно выбрасывает вас на несколько часов.

Часто задаваемые вопросы

Выводы

Сделка Microsoft и Amazon — признак того, что спрос на ИИ-инфраструктуру превышает возможности даже крупнейших игроков. Для разработчиков главное — чтобы GitHub оставался стабильным: следите за статус-страницей сервиса и не используйте GitHub как единственное хранилище критичных данных. Первоисточник: Business Insider.

Amazon Bedrock — управляемый сервис AWS для работы с большими языковыми моделями. Advanced Prompt Optimization — новый модуль внутри него, который принимает шаблон промпта, тестовые данные и критерий оценки, а затем в цикле с обратной связью переписывает промпт до получения лучших результатов по выбранной метрике.

Инструмент запущен 14 мая 2026 года. Он поддерживает мультимодальные входные данные — PNG, JPG и PDF, — что позволяет оптимизировать промпты для задач анализа документов и изображений. Оценку качества можно задать тремя разными способами.

Инструмент оптимизирует промпты для любой модели Bedrock в режиме метрической обратной связи.

Сравнение сразу на 5 моделях одновременно — удобно при миграции.

Три метода оценки: Lambda-функция, LLM-as-a-Judge, steering criteria.

Поддержка мультимодальных входных данных: PNG, JPG, PDF.

Judge-модель по умолчанию — Anthropic Claude Sonnet 4.6.

Доступно в 14 регионах AWS с 14 мая 2026. Оплата — по тарифам инференса Bedrock.

Как работает Advanced Prompt Optimization

Вы подготавливаете шаблон промпта в формате JSONL: описываете переменные, примеры пользовательских данных, опциональные эталонные ответы и метрику оценки. После этого запускаете задачу через консоль Bedrock или API CreateAdvancedPromptOptimizationJob.

Bedrock отправляет ваши шаблоны в выбранные инференс-модели (до 5 штук), оценивает ответы по заданной метрике, затем переписывает промпт и повторяет цикл. На выходе — исходный и финальный шаблоны с оценками качества, оценкой стоимости и задержки.

Формат входного файла

Файл загружается напрямую в консоль или импортируется из Amazon S3. Туда же можно указать директорию для сохранения результатов оптимизации.

Три метода оценки промптов

Lambda-функция

Подходит, если у вас есть конкретная измеримая метрика: accuracy, F1, точность структурированного JSON. Вы разворачиваете Lambda с функцией compute_score, которая программно сравнивает ответ модели с эталонным. Ссылку на Lambda указываете в поле evaluationMetricLambdaArn.

LLM-as-a-Judge

Для открытых задач — суммаризация, генерация, объяснение — где нет жёсткой метрики, но есть рубрика качества. Настраивается через поле customLLMJConfig: задаёте именованные метрики со шкалой оценок, judge-модель проверяет каждую пару промпт—ответ и возвращает оценку с пояснением. По умолчанию в роли судьи — Claude Sonnet 4.6, но можно выбрать другую из доступного списка.

Steering criteria

Самый простой вариант: вы перечисляете критерии в свободной форме — голос бренда, требования к формату, ограничения по безопасности — без написания полного судейского промпта. LLM-judge использует эти критерии для целостной оценки. Judge-модель здесь тоже Claude Sonnet 4.6.

Сценарии использования

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

Улучшение производительности текущей модели. Если менять модель не планируете, выберите только одну. Оптимизатор покажет разницу «до и после» — оценки, стоимость инференса, задержку.

• Анализ документов и изображений (PNG, JPG, PDF как входные переменные)
• Задачи с чёткой метрикой — классификация, извлечение структурированных данных
• Задачи с субъективной оценкой — суммаризация, вопросно-ответные системы, генерация текста
• Тестирование промптов перед выходом в продакшн на эталонных наборах данных

Доступность и стоимость

Advanced Prompt Optimization доступна с 14 мая 2026 года в 14 регионах AWS: США (Северная Вирджиния, Огайо, Орегон), Азиатско-Тихоокеанский регион (Мумбаи, Сеул, Сингапур, Сидней, Токио), Канада (Центральная), Европа (Франкфурт, Ирландия, Лондон, Цюрих), Южная Америка (Сан-Паулу).

Стоимость — по стандартным тарифам инференса Amazon Bedrock: оплата за токены, потреблённые в ходе оптимизации, без отдельной надбавки за сам инструмент.

Как попробовать

1. Откройте консоль Amazon Bedrock и перейдите на страницу Advanced Prompt Optimization.
2. Нажмите Create prompt optimization и выберите до 5 инференс-моделей.
3. Подготовьте JSONL-файл с шаблонами промптов, тестовыми данными и метрикой оценки.
4. Загрузите файл или укажите S3-путь. При необходимости — ссылку на Lambda или рубрику для LLM-as-Judge.
5. Запустите задачу, дождитесь результатов: оптимизированные промпты с оценками и стоимостью.

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

Выводы

Advanced Prompt Optimization в Amazon Bedrock снимает одну из главных болей при работе с LLM — ручной перебор вариантов промптов. Особенно ценен инструмент при смене модели: вместо переписывания промптов вручную можно запустить задачу и получить оптимизированный вариант с понятными метриками качества, стоимости и задержки.

Попробовать инструмент можно в консоли Amazon Bedrock, а техническую документацию и примеры кода — в официальном репозитории AWS на GitHub. Обратная связь принимается через AWS re:Post для Amazon Bedrock.

Прежнее соглашение делало Azure эксклюзивным облачным провайдером для всех API-продуктов OpenAI и обязывало OpenAI продавать API-доступ только через Microsoft — вплоть до момента, когда OpenAI «достигнет AGI» (потребительский ChatGPT и часть веб-продуктов уже могли жить на других облаках по промежуточному соглашению октября 2025-го). В новой версии вместо такой бессрочной формулировки появился календарный срок и право OpenAI работать с другими облаками.

Тот же API, но скоро через несколько облаков. api.openai.com работает как раньше; в ближайшие недели те же модели появятся в AWS Bedrock, дальше — вероятно в Google Cloud.

Лицензия Microsoft неэксклюзивна и до 2032 года. Вместо триггера «до достижения AGI» появилась календарная дата. OpenAI может лицензировать ту же IP другим компаниям.

Azure всё ещё «первый» — но не «единственный». OpenAI запускает на Azure, только если Microsoft технически успевает поддержать новые возможности. Не успеет — продукт может выйти сразу на Bedrock или Google Cloud.

Деньги между компаниями. Microsoft перестаёт платить OpenAI revenue share. OpenAI продолжает платить Microsoft до 2030 года — но теперь с потолком.

Что именно изменилось в договоре

Если выписать пять пунктов из официального заявления Microsoft и OpenAI рядом — картина получается симметричная.

• Эксклюзив по облаку отменён. Раньше любой OpenAI API был доступен только на Azure. Теперь OpenAI может выкатывать продукты на AWS, Google Cloud и где угодно ещё. Azure остаётся «первым» — но только если Microsoft умеет и хочет поддержать соответствующие возможности.
• Эксклюзив по IP отменён. Лицензия Microsoft на OpenAI-модели и продукты теперь неэксклюзивная — то есть OpenAI может лицензировать ту же IP другим компаниям.
• Конкретный срок — 2032 год. Раньше партнёрство действовало «до достижения AGI», то есть на условиях, которые ни одна из сторон не могла формально проверить. Теперь у договора есть календарная дата окончания.
• Microsoft перестаёт делиться выручкой с OpenAI. Раньше Microsoft платил OpenAI часть выручки от продуктов, в которых использовал её модели (например, Copilot). Теперь — нет.
• OpenAI продолжает платить Microsoft до 2030 года, но с потолком. Процент тот же, но появилась суммарная верхняя граница. По оценке TechCrunch, в прошлом квартале Microsoft получил от OpenAI 7,5 миллиарда долларов — после потолка выплаты могут сильно сократиться.

Почему это произошло именно сейчас

Триггером стал февральский анонс инвестиции Amazon в OpenAI на сумму до 50 миллиардов долларов: 15 миллиардов сразу и ещё 35 миллиардов «при выполнении определённых условий». Среди условий — эксклюзивный хостинг OpenAI Frontier (анонсированной агент-платформы) и совместная разработка stateful runtime — слоя памяти, чтобы агент помнил задачу и контекст между обращениями к модели. Условия прямо противоречили действующему договору с Microsoft: тот сохранял за Azure любой OpenAI API.

В тот же день в феврале Microsoft публично опроверг эксклюзив для Amazon: «Azure остаётся единственным облачным провайдером stateless OpenAI API» — и это было прямой цитатой из заявления, на которое потом ссылался TechCrunch. В марте, по сообщению Financial Times, Microsoft рассматривал судебный иск к OpenAI. Новое соглашение — компромисс: Microsoft снимает эксклюзив, но получает гарантированный поток выручки до 2030 года и право не платить revenue share назад.

Хронология: как партнёрство пришло к пересмотру

1. Октябрь 2025. OpenAI и Microsoft заключили промежуточное соглашение, чтобы отбить иск Илона Маска про корпоративную структуру; OpenAI получил право запускать на других облаках свои не-API-продукты (например, потребительский ChatGPT). Параллельно OpenAI обязался потратить ещё 250 миллиардов долларов на Azure-услуги.
2. Ноябрь 2025. OpenAI и Amazon подписали свой первый многолетний контракт на закупку облачных ресурсов AWS на 38 миллиардов долларов (это плата OpenAI за инфраструктуру, не инвестиция Amazon).
3. Февраль 2026. Amazon анонсировал инвестицию до 50 миллиардов долларов в саму OpenAI: 15 миллиардов сразу и ещё 35 «при выполнении условий». Среди условий — эксклюзивный хостинг Frontier (агент-конструктор OpenAI) и stateful runtime на AWS Bedrock. В тот же день Microsoft публично заявил: эксклюзив на API остаётся за Azure.
4. Март 2026. Financial Times сообщила, что Microsoft рассматривает судебный иск к OpenAI.
5. 27 апреля 2026. Стороны выкатили новое соглашение с фиксированной датой 2032 года и отменой эксклюзивов в обе стороны.

Что это значит для тех, кто строит на OpenAI

Что меняется для пользователей OpenAI API

Краткосрочно — ничего не ломается: ваши вызовы к api.openai.com работают как раньше. В среднесрочной перспективе у вас появятся варианты: те же модели, по тому же API можно будет дёргать через AWS Bedrock и, скорее всего, через Google Cloud. Это снижает облачный lock-in, если вы хотите диверсифицировать инфраструктуру или платите за облачный egress между провайдерами. Перечитайте свой договор с Azure OpenAI Service и прикиньте, что вы сделаете, когда те же модели станут доступны через Bedrock.

Что меняется для Azure OpenAI Service

Azure OpenAI Service остаётся, и Microsoft по-прежнему «основной облачный партнёр» — то есть новые модели будут появляться на нём первыми. Но фразу «Azure-only OpenAI» из архитектурных решений можно убирать: соглашение прямо позволяет OpenAI стартовать продукт где-то ещё, если Microsoft не успевает или не хочет поддержать новые возможности. Если вашему стеку требуется суверенитет данных или конкретная региональная доступность — у вас теперь больше выбора, в том числе через AWS-регионы.

Stateful runtime, Frontier и агенты

Frontier — анонсированная агент-платформа OpenAI: инструмент, чтобы строить агентов с долгой памятью и доступом к инструментам. Stateful runtime — слой, который хранит состояние агента между обращениями к модели (чтобы агент помнил задачу, контекст и промежуточные результаты, а не пересобирал их каждый раз). По февральскому соглашению Amazon должен был получить эксклюзив на хостинг и Frontier, и stateful runtime — именно этот пункт противоречил договору с Microsoft. Новое соглашение этот эксклюзив снимает: stateful runtime у OpenAI всё ещё может быть «на Bedrock», но без обещания Amazon, что больше нигде.

Что отсюда забрать разработчику

Главное смысловое изменение — закончилась эра, когда OpenAI был «вертикалью Microsoft». Теперь это самостоятельный API-вендор, чьи модели можно тащить через любой облачный провайдер. Для архитектурных решений это значит, что предположение «OpenAI = Azure» можно убирать из дизайн-документов, а multi-cloud-стратегии становятся реалистичнее без обходных манёвров.

Microsoft при этом не остался в проигрыше: 27% коммерческой части OpenAI как акционер, потолок на исходящие revenue share и параллельное углубление отношений с Anthropic — Claude теперь питает агентные продукты Microsoft. Для бизнеса это значит, что между крупными модельными вендорами и облаками появилось пространство для торга по цене, латентности и регионам.

Сегодня — конкретный шаг: посмотрите в lock-файлах и infra-as-code, какие пункты у вас завязаны на Azure-only OpenAI, и заведите тикет на параметризацию провайдера. Источники: Microsoft Blog, OpenAI announcement, TechCrunch, CNBC.

По данным источников Financial Times, инженеры позволили агентному ассистенту Kiro внести изменения в систему без дополнительного ручного контроля. Алгоритм решил, что оптимальный способ устранить проблему — «удалить и пересоздать окружение».

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

Что случилось

Kiro — новейший код-ассистент AWS, представленный летом. Он способен не просто генерировать код, а выполнять действия от имени пользователя. В данном случае инструмент получил права, сопоставимые с правами оператора, и действовал автономно.

По словам сотрудников, это уже второй инцидент за последние месяцы, где ИИ-инструменты оказались вовлечены в производственные сбои. Ранее проблемы связывали с Amazon Q Developer — чат-ботом для программистов.

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

Насколько это серьезно

Декабрьский сбой был ограниченным — затронул один сервис и не стал сопоставимым с масштабным 15-часовым падением AWS в октябре 2025 года. Тогда, напомним, недоступными оказались приложения множества клиентов, включая ChatGPT.

Тем не менее, сам факт вызывает вопросы. AWS приносит около 60% операционной прибыли Amazon. И именно сейчас компания активно продвигает ИИ-агентов как продукт для внешних клиентов.

Внутренние сбои подрывают доверие к идее «автономных ассистентов», которые могут действовать без второго уровня проверки.

За 8 лет в бигтехе он видел несколько волн изменений, но текущую считает самой радикальной. Главный сдвиг — ИИ больше не бонус, а базовое ожидание.

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

Что изменилось в требованиях к кандидатам

Еще в 2020 году достаточно было хорошо решать задачи на алгоритмы и уверенно разбираться в system design. Сегодня это лишь минимальный уровень.

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

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

Отдельно ценится умение исправлять ошибки ИИ, потому что, как отмечает Хазарика, «модель часто ошибается в базовой логике».

Как поменялись собеседования

Формально интервью все еще проверяют алгоритмы, структуры данных и мышление. Но появились новые форматы.

В некоторых компаниях кандидатам разрешают использовать ИИ прямо во время интервью — в режиме шаринга экрана.

Хазарика вспоминает собеседование в стартапе в 2024 году, где ему дали большой файл с багом и прямо разрешили подключить ИИ. Он решил писать код сам и в итоге провалил интервью. Этот опыт стал для него сигналом: игнорировать ИИ — значит играть против правил.

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

Что советуют новичкам и опытным инженерам

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

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

Общий же вывод Хазарики прост: рынок скорее ищет не кодеров или промт-инженеров, а гибридов. Тех, кто понимает фундаментальную инженерию и умеет использовать ИИ как инструмент, а не костыль.

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

Проблемы тянутся еще с октября, когда поставки NAND от ключевых производителей — Samsung и SanDisk — внезапно остановились. Цепочка разорвалась и пошли массовые перебои. Из-за этого срывались контракты, а заказы невозможно было выполнить.

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

Amazon, Microsoft и другие крупные игроки выкупают огромные объемы NAND под собственные кластерные потребности. На традиционный рынок уходят жалкие остатки и цены там взлетают до небес.

Производители уходят с рынка один за другим

Кризис уже выбивает старых игроков. Crucial — один из самых известных брендов SSD и оперативной памяти — фактически закрывает потребительское направление.

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

Micron, владелец Crucial, объясняет решение нестабильностью бизнеса. Спрос смещается в промышленный и серверный сегменты, а массовые устройства тонут в дефиците и дорожающих компонентах. По словам компании, рынок «разрывает» спрос со стороны ИИ-кластеров и ферм на базе GPU NVIDIA и AMD. Туда же утекают NAND и DRAM.

Дефицит будет только усиливаться

Transcend не считает происходящее временным. Компания ждет, что давление на цепочки поставок сохранится еще минимум от трех до пяти месяцев, а пик кризиса придется на конец 2025 — начало 2026 года.

Это подтверждают и отраслевые источники. SanDisk уже подняла контрактные цены на NAND на 50%. Innolux и Apacer предупредили партнеров о срыве поставок и невозможности выполнять обязательства.

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

По данным Detector404, сервис зафиксировал более 1400 жалоб всего за сутки. При этом по подсчетам сервиса, с проблемой и вовсе столкнулось до 65 000 человек.

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

На данный момент проблемы отмечаются в 25 городах — от крупных региональных центров (вроде Москвы и Екатеринбурга) до небольших населенных пунктов.

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

Как реагируют пользователи

В комментариях на сервисах мониторинга началась типичная паника.

Одни уверены, что «Roblox заблокировали в России навсегда», другие предполагают проблемы на стороне Amazon. Именно там размещается часть инфраструктуры игры.

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

Что известно о причинах

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

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

Появились и громкие заявления: например, автор книги «Империя ИИ» Карен Хао считает, что OpenAI уже обладает влиянием, сравнимым с государствами.

Мир в ожидании перемен

Обозреватель The Atlantic Чарли Варзел пишет, что мы живем «в мире, который построил ChatGPT» — мире нестабильности и ожидания следующего скачка технологий.

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

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

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

Как ИИ перестроил рынок капитала

По данным Bloomberg, эффект ChatGPT особенно заметен на фондовом рынке. Главный выигрывающий от происходящего игрок — NVIDIA. Ее графические процессоры стали основой ИИ-индустрии. Так, с момента запуска ChatGPT, акции компании выросли на 979%.

Вслед за ней ускорились и другие гиганты: Microsoft, Apple, Alphabet, Amazon, Broadcom. Теперь семь крупнейших компаний формируют 35% индекса S&P 500 — такой концентрации не было никогда.

Но внутри индустрии звучат и предупреждения. Гендиректор OpenAI Сэм Альтман открыто признает, что «кто-то потеряет феноменальные деньги на ИИ».

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

Как заявил CEO компании Сатья Наделла в подкасте BG2Pod, рост штата больше не будет выглядеть как «возврат к доковидным временам»:

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

Нанимают меньше — но «умнее»

За последние полтора года Microsoft сократила более 15 000 человек, оптимизируя структуры вокруг инвестиций в ИИ. Теперь компания формирует «AI-first» штат, где ключевую роль в подборе и работе сотрудников играют нейросети.

Наделла подчеркнул, что все процессы — от исследований до планирования — теперь начинаются с ИИ:

«Вы исследуете с помощью ИИ, думаете с помощью ИИ и делитесь результатами через него».

На практике это значит, что Copilot и другие внутренние инструменты Microsoft уже встроены в каждое звено работы — от офиса до DevOps.

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

AI-кадры вместо классических специалистов

Microsoft больше не восстанавливает массово «старые» роли. Приоритет теперь у направлений, связанных с развитием искусственного интеллекта:

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

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

Новый тренд для индустрии

Пока Google и Amazon продолжают сокращения, Microsoft делает ставку на рост производительности через ИИ, а не просто экономию расходов.

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

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

Проблемы зафиксированы у Perplexity, Fortnite, Steam, Snapchat, Asana, Roblox, Duolingo, Coinbase, Canva, Venmo, McDonald’s, Apple TV и множества других платформ, завязанных на инфраструктуру AWS.

Согласно данным Downdetector, пик жалоб пришелся на 11:00 МСК, когда было зафиксировано более 5700 обращений, хотя реальное число пострадавших, вероятно, значительно выше.

Половина интернета — в офлайне

AWS — это не просто сервис Amazon, а фундаментальная часть интернета. Она обеспечивает работу миллионов веб-приложений, API и баз данных.

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

Показательно, что даже панель статуса AWS Health Dashboard в момент инцидента оказалась недоступна, выдавая ошибку «This site can’t be reached».

Что известно о причинах

Официальных комментариев от Amazon на момент публикации нет, но все признаки указывают на проблемы в восточном регионе Вирджинии (us-east-1) — ключевом узле AWS, через который проходит значительная часть мирового трафика.

Компания Perplexity AI одной из первых подтвердила зависимость инцидента от инфраструктуры AWS.

Perplexity сейчас не работает. Причина — сбой на стороне AWS. Мы уже занимаемся восстановлением.

С аналогичным сообщением выступили представители Asana, которые сообщили о «полной недоступности всех сервисов» и ожидании обновления от Amazon.

Реакция пользователей

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

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

Что дальше

AWS пока не раскрывает детали, но инженеры компании, по данным внутренних каналов, уже работают над «локализацией и перезапуском кластеров в Вирджинии».

Сбои AWS происходят редко, но их эффект показывает, насколько уязвим современный интернет: когда падает Amazon — падает и все остальное.

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

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

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

По сути, это документ, в котором фиксируются все изменения, внесённые в архитектуру: само решение, его влияние и полученные уроки.

Проще говоря, это как личный дневник — только для всей команды.

Почему это важно?

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

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

Будущие разработчики скажут вам спасибо. Подумайте о человеке, который через пять лет будет разбираться в вашем коде. Если вы не оставили объяснений, он, скорее всего, будет мучиться, пытаясь понять, зачем было сделано то или иное изменение. А теперь представьте другого разработчика в другой компании, который находит ADR-документ с чётким объяснением принятого решения. Он, без сомнения, будет вам благодарен.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

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

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

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

В подкасте Matthew Berman Show он назвал это «одной из самых глупых идей», которые он когда-либо слышал.

Почему это плохая стратегия

По словам Гармана, джуниоры — одни из самых недорогих и гибких сотрудников. Они активно осваивают инструменты ИИ и растут вместе с ними.

Если компания откажется от найма младших специалистов, это ударит по ее кадровому резерву в будущем:

Что вы будете делать через 10 лет, если у вас не будет людей, которые чему-то научились и выросли внутри компании?

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

Университетское образование теряет монополию

Также он отметил, что в условиях экономики, где ИИ играет ключевую роль, ценность не в конкретных дипломах, а в гибкости и способности адаптироваться:

Если вы потратите годы на изучение одного узкого направления и решите стать в нем экспертом на 30 лет вперед — могу с уверенностью сказать: это не сработает.

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

Что говорят другие эксперты

Заявление Гармана резко контрастирует с позицией некоторых лидеров индустрии. Например:

• Сэм Альтман (OpenAI) ранее сравнил ИИ-агентов с младшими сотрудниками, чья работа все чаще автоматизируется.
• Джефф Дин (Google) заявил, что ИИ достиг уровня, на котором может повторить навыки начинающего инженера — и это произойдет уже в ближайший год.
• По данным Goldman Sachs, безработица среди молодых специалистов в IT (20–30 лет) выросла почти на 3% с начала 2024 года — в четыре раза быстрее, чем в среднем по рынку.

Почему джуниоры все еще важны

Однако не все считают, что молодые кадры устарели. CEO GitHub Томас Домке также отметил: именно начинающие инженеры быстрее всего адаптируются к новым технологиям, включая ИИ:

Они не ограничены подходом «мы всегда делали так». Для них ИИ — это естественный инструмент, а не революция.

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

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

Но тогда их власть была не в профсоюзах, а в дефиците:

Если ты получаешь по пять писем от рекрутеров в день — тебе не нужен профсоюз, чтобы послать начальника к чёрту

От «святых миссий» — к массовым увольнениям

Компании, по мнению Доктороу, сознательно культивировали у разработчиков «профессиональный пиетет» — веру в то, что их работа спасает мир.

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

Разработчиков начали увольнять сотнями тысяч, а оставшихся перегружают чужой работой. В *Meta сокращения совпали с ростом бонусов топ-менеджеров, в Google основатель призывает к 60-часовой неделе, в Amazon менеджеры снова садятся писать код.

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

Тот же класс — та же борьба

Кори Доктороу делает важный вывод: разработчики — это просто работники. Те же, что на заводах, в складах, в доставке.

И если раньше их спасал дефицит, то теперь — нет. И единственный путь сохранить свои права и условия — это солидарность и профсоюзы.

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

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

Что входит

В новый тариф входит:

• $100 кредитов при регистрации;
• плюс до $100 дополнительных бонусов за выполнение простых заданий: например, запуск и завершение EC2-инстанса или создание веб-приложения с Lambda;
• уведомления о снижении баланса (50%, 25%, 10%) и приближении конца срока (15, 7 и 2 дня до окончания).

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

После апгрейда до платного аккаунта, сохраняются оставшиеся кредиты — их можно использовать ещё до 12 месяцев с момента регистрации.

Ограничения

Некоторые корпоративные сервисы будут недоступны на бесплатном тарифе. Переход на платный тариф открывает полный доступ.

Контекст

Этот шаг сближает AWS с другими облачными гигантами:

• Azure: $200 на 30 дней + 25 сервисов навсегда бесплатно
• GCP: $300 на 90 дней + постоянный бесплатный доступ к ряду ключевых сервисов

Старый 12-месячный бесплатный тариф AWS прекращает действовать 15 июля 2025 года. Зарегистрированные до этой даты пользователи останутся на прежних условиях.

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

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

Причины массового игнорирования: системные ловушки

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

Большой объем и языковой барьер

Современные соглашения напоминают юридические трактаты. Средний документ российских сервисов содержит 16,800 слов. Роскомнадзор критикует избыточность текстов, но не публикует официальной статистики. Например, документация Ozon занимает 23,700 слов — это больше, чем повесть Чехова «Дуэль» (13,700 слов). Политика Яндекс.Диска занимает 57 страниц, а условия СберБанк Онлайн — 43 страницы.

Главная проблема — язык. Юридические термины вроде «сублицензирование», «деперсонализация данных» или «арбитражная оговорка» требуют специальных знаний. Как показывает практика судебных споров и жалоб в Роскомнадзор, такие формулировки часто непонятны рядовым пользователям. Барьер усугубляется тем, что юридическая грамотность в РФ остается низкой: далеко не все россияне уверенно читают договоры.

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

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

UX-дизайн, провоцирующий спешку

Современные интерфейсы часто проектируются так, что внимательное прочтение соглашений становится затруднительным. Кнопка «Принять» обычно выделяется контрастным цветом (например, зеленым или синим), а опция отказа скрывается:

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

Такие паттерны усиливают «эффект туннельного зрения» — психологический феномен, при котором пользователь фокусируется на цели (быстром доступе к сервису), игнорируя второстепенные элементы. Дизайнеры дополнительно стимулируют это: например, используют таймеры обратного отсчета («Осталось 00:59»), чем создают искусственную спешку. Сообщения типа «99% пользователей уже приняли условия» формируют социальное давление.

Мнимый выбор в условиях монополий

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

Почему выбор остаётся мнимым? Попробуйте использовать СберБанк Онлайн без принятия политики обработки данных. Система выдаст ошибку: «Для продолжения необходимо согласиться с условиями». Аналогично в VK: отказ от соглашения означает потерю доступа к сообщениям и группам.

Мнимый выбор — это не всегда подвох со стороны сервиса. Даже по новым европейским правилам (Digital Services Act) платформы должны давать вам «базовую версию» без персонализированной рекламы, но не обязаны работать вообще без сбора данных.

В России всё устроено схоже: если без ваших персональных данных сервис просто не сможет функционировать (например, банк или мессенджер), отказ в доступе — это не нарушение закона.

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

Евросоюз в 2024 году ввел Digital Services Act, обязывающий платформы предлагать базовую версию без сбора данных. В России аналогичные нормы в законе «О персональных данных» (152-ФЗ) начали работать только с 2025 года. У пользователя есть право отозвать согласие на обработку данных, но не все сервисы готовы сохранять функционал после отказа.

Что скрывают соглашения: реалии цифрового мира

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

Расширенный сбор данных под видом «аналитики»

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

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

После ухода зарубежных сервисов российские платформы переняли спорные методы: например, VK Мессенджер хранит метаданные переписки (время отправки, IP-адреса, идентификаторы устройств) два года — дольше, чем это необходимо для операционной деятельности.

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

Формулировки про «хранение данных столько, сколько нужно для бизнеса» выглядят довольно расплывчато и, с юридической точки зрения, не могут считаться самостоятельной и достаточной целью: такая причина хранения вряд ли будет признана обоснованной при проверке. Тем не менее, именно за такими фразами иногда скрывают ссылку на так называемый законный интерес — этот механизм широко применяется в Европе по стандарту GDPR. В России, напротив, операторы редко ссылаются на законный интерес напрямую: это связано с тем, что у нас сложнее требования к обоснованию сроков и объёмов хранения данных, и риски для компании выше.

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

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

Умные колонки с голосовыми помощниками (такие как «Яндекс.Станция» или устройства Sber) постоянно анализируют звуковое окружение для активации по ключевым словам, что создает риск случайной записи приватных разговоров.

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

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

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

Исследования подтверждают:

• Ложные срабатывания. Ассистенты активируются до 19 раз в сутки из-за фоновой речи, слов-омофонов или аудиоконтента (например, при просмотре сериалов).
• Технические уязвимости. Ученые обнаружили, что MEMS-микрофоны в таких устройствах излучают радиосигналы, которые можно перехватить FM-приемником даже через бетонные стены.
• Хранение данных. Записи голосовых команд сохраняются на серверах производителей неограниченное время. В 2019 году сотрудники Amazon признались в прослушке аудио с Echo без ведома пользователей.

Как минимизировать угрозы:

1. Отключайте микрофоны колонок физической кнопкой (если есть) при обсуждении конфиденциальных тем.
2. Откажитесь в настройках от «персонализированных ответов» и отправки аудиоданных для «улучшения сервиса».
3. Регулярно удаляйте историю запросов через приложение-компаньон (например, «Дом с Алисой»).

Важно: Пользовательское соглашение «Яндекса» прямо разрешает обработку фонового аудио для «технического анализа», но не уточняет сроки хранения или алгоритмы фильтрации. Для устройств Sber аналогичные условия описаны в разделе «Данные голосового взаимодействия».

Передача прав на контент

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

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

Автоматическое продление подписок

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

• Сервис IVI продлевает платный доступ без отдельного подтверждения после пробного периода.
• Яндекс.Плюс списывает средства за 3 дня до окончания расчетного цикла в случае, если юзер не отключил автопродление. Яндекс делает это, «чтобы обеспечить клиентам непрерывный доступ к сервису, даже если платеж задерживается».

Особую опасность представляют детские приложения, где случайные покупки происходят из-за неочевидного интерфейса. В 2024 году Федеральная торговая комиссия США (FTC) оштрафовала Epic Games (американскую компанию по разработке игр и ПО) в общей сложности на $520 млн за сложную процедуру отмены несанкционированных платежей в Fortnite (кроссплатформенной формально бесплатной игре).

Российские сервисы могут использовать схожие паттерны:

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

Ещё несколько лет назад — и в зарубежных, и в российских сервисах — действовали более лояльные правила возврата: если пользователь забывал отменить подписку в течение льготного периода, деньги можно было вернуть. По данным на 2021 год, такую опцию предлагали и IVI, и Яндекс, и Okko.

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

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

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

Как защитить себя: стратегии для 2025 года

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

Для пользователей: цифровая гигиена

Проверяйте репутацию сервиса перед согласием

Роскомнадзор ведёт открытый реестр нарушителей закона 152-ФЗ. Например, каршеринг «Делимобиль» был внесен в список после массовой утечки номеров телефонов.

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

Жёстко контролируйте разрешения

Современные ОС предлагают инструменты для защиты:

• в Android 14 функция «Одноразовый доступ» ограничивает работу камеры/микрофона одним сеансом;
• в iOS 18 «Детальный контроль» позволяет блокировать фоновый сбор данных.

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

Требуйте отчёт о ваших данных

Статья 14 закона 152-ФЗ гарантирует право запросить у компании:

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

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

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

И если вас ответ не устроил, вы вправе требовать удаления ваших персональных данных - оператор обязан будет это сделать (кроме тех данных, которые он обязан хранить в силу закона). Правда, нередко это одновременно будет означать, что вы не сможете более пользоваться этим сервисом.

Для разработчиков: прозрачность как конкурентное преимущество

Сокращайте и визуализируйте соглашения

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

Внедряйте градацию согласия

Разделите запросы на данные по категориям:

• базовые — необходимые для работы сервиса;
• опциональные — аналитика, реклама, улучшение продукта.

Европейский GDPR требует такой практики — например, при установке приложения Signal пользователь отдельно разрешает доступ к контактам и уведомлениям. В России подобный подход выделит ваш продукт на фоне конкурентов.

Добавьте «режим адвоката»

Встройте в интерфейс кнопку «Главные риски за 60 секунд»: краткую выжимку ключевых положений. Сервис ProtonMail делает это эффективно — на странице регистрации четко указано: «Мы не храним IP-адреса и не передаём данные третьим лицам».

Будущее соглашений: нейросети и законодательство

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

ИИ-ассистенты: возможности и ограничения

Крупные IT-компании разрабатывают инструменты для анализа юридических документов. Яндекс.Помощник интегрировал функцию сканирования соглашений: система выделяет спорные пункты цветными маркерами и генерирует упрощенные пояснения.

Однако нейросети не заменяют юристов. ИИ-сервисы нередко пропускают скрытые условия в длинных документах.

Основные проблемы:

• неспособность интерпретировать двусмысленные формулировки;
• игнорирование ссылок на внешние документы;
• ошибки в трактовке арбитражных оговорок.

Законодательные изменения: новые требования

В июне 2024 года принят Федеральный закон № 123-ФЗ, вносящий поправки в 152-ФЗ.

Ключевые новации:

• запрет автоматического продления платных подписок без отдельного подтверждения через SMS или email (ст. 15.4);
• обязательное выделение условий сбора биометрических данных жирным шрифтом;
• штрафы до 3% годового оборота за сокрытие практик передачи данных третьим лицам.

Новые требования уже дают результаты.

Перспективы: стандартизация и блокчейн

ЕС разрабатывает AI Act — единый стандарт для ИИ-анализа соглашений. Эксперименты с блокчейн-реестрами условий проводят Сбербанк и Тинькофф: технология фиксирует версии документов и предотвращает скрытые изменения.

Заключение: ваша цифровая подпись — это ответственность

Пользовательские соглашения — не формальность, а юридически обязывающий документ. Их игнорирование в 2025 году связано со многими рисками. Каждый клик «Принять» несёт реальные последствия: от скрытой слежки до потери прав на контент.

Что делать сегодня? Начните с малого. Даже беглый просмотр разделов «Данные» и «Автоматическое продление» снижает риски. Не забывайте о законе 152-ФЗ. Если это необходимо, требуйте от компаний полный отчёт о ваших данных через форму на портале Роскомнадзора.

Голосуйте кошельком. Переходите на сервисы с прозрачными правилами. Осознанное согласие — не роскошь, а базовый навык цифровой эпохи. Ваши данные стоят тех 10 минут, которые вы потратите на чтение перед кликом «Принять».

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

Бонус — комментарии экспертов с многолетним опытом работы за границей и глубоким пониманием международного рынка труда.

Какие IT-профессии наиболее востребованы за рубежом

По данным сервиса по поиску работы HeadHunter, в 2024 году наибольшим спросом за границей пользовались российские:

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Российские IT-специалисты всё ещё остаются востребованными за рубежом, но по сравнению с 2022 годом ситуация изменилась. Международные компании уже не так охотно берут в штат сотрудников из России, известны случаи сокращений из-за гражданства. Причина — политика компаний, особенно тех, которые решили покинуть российский рынок. Зато за последние три года многие отечественные стартапы релоцировались в другие страны, и они отдают предпочтение сотрудникам из России.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Языки программирования, актуальные для иностранных компаний

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

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

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

Дополнительное преимущество — оплата в валюте: долларах, евро или фунтах. После пересчёта на рубли итоговая сумма все равно будет выше средней зарплаты в России — и это без учёта премий и бонусов.

Где IT-кадры пользуются спросом

Найти работу в IT сейчас везде нелегко, но чуть проще это сделать там, где активно развивается IT-сектор и требуется много кадров соответствующего профиля:

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

По данным HeadHunter, активнее всего российских специалистов приглашают на работу компании из:

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Не все страны охотно принимают специалистов из других стран. Если раньше одними из самых популярных направлений для релокации были Канада и США, то сейчас переехать туда стало значительно сложнее. Больше шансов на трудоустройство в компании Испании, Португалии, Кипра, ОАЭ.

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

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

Вот подборка сайтов для поиска работы за границей:

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Удобнее всего искать вакансии зарубежных компаний через LinkedIn. По моему опыту, большинство специалистов находят работу за границей именно через эту площадку. Но есть и альтернативные варианты — например, телеграм-каналы с профильными вакансиями. Будьте готовы к тому, что придётся отправлять много откликов. В среднем на 100 откликов приходится не более 5 ответов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

В основном я искал работу через LinkedIn. Это самая эффективная платформа: я обновил профиль, загрузил резюме и активно взаимодействовал с рекрутерами. Также полезно размещать резюме на популярных job-порталах и быть открытым к предложениям — тогда многие специалисты по подбору персонала сами выходят на связь.

2. Адаптируйте резюме для иностранного рынка

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

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

Кроме того, в некоторых странах, например, Великобритании, США и Канаде не принято добавлять фото в резюме. Такое правило стало следствием законов против дискриминации в этих странах, поэтому его несоблюдение может вызвать негативную реакцию и привести к мгновенному отказу.

Дополнительно к резюме стоит приложить мотивационное письмо (Cover Letter), подготовленное специально под конкретную вакансию. В мотивационном письме уже не пишут об образовании и навыках — эти сведения указывают только в резюме. А в Cover Letter особый упор делается на кейсах и объяснении, чем для вас интересна компания и почему вы для неё — самый подходящий кандидат.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

3. Обратитесь в агентство по трудоустройству

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

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

Агентства также консультируют по вопросам адаптации и помогают с поиском жилья.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

Digital Nomad Visa. Digital Nomad Visa или «виза цифрового кочевника» позволяет легально жить за рубежом, но при этом продолжать удалённо работать на родину. В отличие от туристической визы, Digital Nomad Visa даёт право длительно находиться в определённой стране, а в сравнении с рабочей визой — не требует трудоустройства на местном рынке.

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

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

Фриланс — самый простой способ начать работать с зарубежными компаниями без лишней бюрократии и сложностей с оформлением. Достаточно зарегистрироваться на зарубежную фриланс-платформах Upwork или Fiverr, и можно сразу браться за международные проекты. Единственное, могут возникнуть трудности с оплатой, поэтому стоит завести себе иностранную банковскую карту.

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

Официальное трудоустройство с релокацией

Официальное трудоустройство гарантирует стабильную зарплату и полный соцпакет, а при релокации — помощь с переездом и адаптацией в новой стране.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Какой уровень владения английским языком нужен

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Обязательное требование — свободное владение английским: например, в Португалии большинство сотрудников IT-компаний общаются на нём. Но иногда кандидату необходимо знание местных языков — так, если вы хотите переехать во Францию, шансы на трудоустройство без владения французским минимальны.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Коротко о главном

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

Это бесплатная IDE, усиленная искусственным интеллектом. По сути, Kiro становится прямым конкурентом популярного Cursor, предлагая аналогичный подход, но с рядом уникальных функций.

Что такое Kiro

Kiro — это ИИ-IDE, построенный по принципу спецификационного программирования. Программа превращает текстовые запросы в четкие требования, архитектуру системы и конкретные задачи.

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

Особенность Kiro — так называемые агентные хуки. Они позволяют делегировать рутинные задачи ИИ-агентам, которые запускаются автоматически при определенных событиях.

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

Почему это важно

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

Таким образом, разработка становится управляемой и предсказуемой.

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

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

Совместимость и технологии

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

Кроме того, в основе Kiro работают модели Claude Sonnet 3.7 и 4, с возможностью выбора и обновлений в будущем.

Отдельно стоит отметить режим автопилота. В нем Kiro способен выполнять объемные задачи без постоянного контроля со стороны человека. При этом у разработчика остается управление — может корректировать результаты и вмешиваться при необходимости.

Кризис доткомов 2000 года оставил на рынке только сильнейших. Amazon и eBay выжили, Pets.com с их говорящим щенком-талисманом разорились, потратив $300 млн на рекламу. В России в это время аудитория Рунета медленно, но стабильно росла (около 3-5 млн юзеров), однако онлайн-торговля была делом энтузиастов.

Какими были первые шаги сектора e-commerce, как торговали через интернет в начале тысячелетия, кто и что продавал — обо всем этом и многом другом читайте в нашем историческом исследовании.

Мир в 2001: первые шаги глобального онлайн-шопинга

В 2001 году онлайн-шопинг был мероприятием с сомнительными шансами. Без алгоритмов, быстрой доставки и защищенных платежей. Но именно тогда первые продавцы заложили основы e-commerce, которые работают до сих пор.

Технологии: как покупали без маркетплейсов

В 2001 году для покупки в интернете нужны были три вещи: браузер Netscape Navigator с поддержкой SSL-шифрования, кредитная карта и железное терпение. PayPal только появился (1998 год), но большинство предпочитало оплачивать наличными курьеру или банковским переводом.

Доставка — отдельная история. Amazon доставлял книги по США за 3-5 дней, но международные заказы могли идти месяцами. DHL и FedEx доминировали, стоимость перевозки из США в Россию достигала $50 за небольшую посылку.

Главные игроки: кто правил e-commerce

В 2001 году мировая онлайн-торговля строилась практически с нуля: несколько крупных игроков делили рынок, а остальные боролись за выживание. Amazon, eBay и Alibaba — эти три компании определили будущее e-commerce, но их пути различались кардинально.

Amazon

К 2001 году Amazon уже перестал быть просто книжным магазином. Джефф Безос агрессивно расширял ассортимент: CD, DVD, электроника, игрушки. Выручка компании достигла $3.1 млрд, но прибыль появилась лишь в 2003-м — до этого все заработанное вкладывали в рост.

Главным прорывом Amazon стали персонализированные рекомендации. Алгоритм анализировал покупки и предлагал товар по принципу: «Клиенты, купившие эту книгу, также брали вот эту». Это увеличивало средний чек и создавало эффект «длинного хвоста» — даже нишевые товары находили покупателей.

Однако не все шло гладко. После кризиса доткомов акции Amazon упали на 90%, аналитики заговорили о банкротстве. Компанию спасли два решения: партнерство с другими ритейлерами (например, Toys “R” Us) и ставка на технологическую инфраструктуру — именно тогда заложили основы AWS.

eBay

Площадка eBay в 2001-м — это царство аукционов. Здесь продавали все: от винтажных открыток до раритетных автомобилей. Платформа работала по принципу C2C (потребитель — потребитель), а ее главной «фишкой» была система рейтингов продавцов.

Но проблема заключалась в платежах. Большинство сделок совершалось через чеки или денежные переводы, что замедляло процесс. В 2002 году eBay купил PayPal за $1.5 млрд, чтобы решить этот вопрос. Интересно, что изначально у eBay был собственный платежный сервис Billpoint, но он проигрывал PayPal по популярности. Причины — сложный интерфейс и высокие комиссии.

После сделки PayPal сохранил бренд, но eBay постепенно свернул Billpoint. Это решение оказалось ключевым: к 2004 году 70% транзакций на eBay проходили через PayPal.

Alibaba

Основанная в 1999 году китайским предпринимателем Джеком Ма, Alibaba в 2001-м была далека от современного гиганта. Компания фокусировалась на B2B-сегменте, соединяя производителей из КНР с мировыми покупателями. Главный продукт — Alibaba.com — работал как каталог оптовых товаров: от текстиля до электронных компонентов.

Розничная платформа Taobao появится только в 2003-м, а AliExpress — в 2010-м. Но уже тогда Alibaba заложила основы успеха: бесплатные объявления для продавцов, акцент на малый бизнес и агрессивная маркетинговая стратегия в Азии.

Интересный факт: в 2001 году Alibaba едва не обанкротилась. Компанию спасло $25 млн инвестиций от SoftBank — эти деньги позволили пережить кризис доткомов.

Провалы и курьезы

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

Webvan — стартап с доставкой продуктов. Инвесторы вложили $1.2 млрд, но компания обанкротилась в 2001-м. Причина — неверный расчет спроса и гигантские затраты на склады.

Россия 2001: онлайн-шопинг в эпоху dial-up

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

Технические ограничения

Интернет в России был медленным (56 кбит/с через телефонную связь) и неравномерным. 60% аудитории Рунета жили в Москве и Питере, регионы отставали.

Платежи — отдельная боль. PayPal в России не работал, а «КиберПлат» (первая российская платежная система) требовал кучу документов. Основные способы оплаты: наличные курьеру или банковский перевод с комиссией 3-5%.

Первые российские интернет-магазины

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

Ozon.ru

Основанный в 1998 году, Ozon к 2001-му стал флагманом российского онлайн-ритейла, хотя масштабы его работы сегодня вызывают снисходительную улыбку. Созданный по образу и подобию Amazon, магазин начинал с продажи книг, но быстро расширил ассортимент до 10 тысяч товаров, включая CD, DVD и бытовую технику.

Интересно, что логистика Ozon сильно отличалась от современных стандартов. Курьеры действительно ездили на метро, а не на машинах, что делало доставку непредсказуемой по времени. Один из первых топовых заказов у покупателей — книга «Гарри Поттер и Кубок огня» за 120 рублей — стал своеобразным символом новой эпохи.

Проблем у Ozon было немало: только 30% заказов оплачивались онлайн, остальные — наличными доставщикам. Компания даже ввела рейтинг «проверенных продавцов», пытаясь бороться с недоверием покупателей. В 2001 году Ozon обрабатывал несколько сотен заказов в день — смешная цифра по современным меркам.

Утконос

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

Основные заказы принимались по телефону — сайт служил скорее каталогом, чем торговой площадкой. Ассортимент насчитывал около 500 позиций, причем везти товар могли несколько дней — о «доставке за 15 минут» тогда не было и речи.

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

Другие игроки

Российский e-commerce 2001 года был представлен и другими любопытными проектами, большинство из которых не дожили до наших дней.

«Молоток.ру», созданный как аналог eBay, предлагал аукционную систему торговли. Однако низкий интернет-охват и недоверие к подобным схемам привели к закрытию уже в 2003 году.

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

Отдельного упоминания заслуживает сервис «24×7» — один из первых интернет-супермаркетов, предлагавший доставку товаров круглосуточно. Его судьба показательна: несмотря на инновационность идеи, недостаточное развитие логистической инфраструктуры привело к краху проекта.

Почему россияне не доверяли онлайн-покупкам?

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

Страх обмана

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

Ситуацию усугубляли реальные случаи обмана. В архивах Роспотребнадзора сохранились данные о массовых жалобах на интернет-магазины в 2001-2003 годах: от банальной недопоставки товара до откровенного мошенничества с предоплатой. При этом механизмы защиты прав потребителей практически отсутствовали — вернуть деньги за купленный онлайн некачественный товар было крайне сложно.

Правовая неопределенность

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

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

• обязательное указание полной информации о продавце;
• правила оформления онлайн-договоров;
• сроки доставки товаров;
• ответственность за нарушение обязательств.

Культурные особенности

Российские потребители традиционно предпочитали «пощупать» товар перед покупкой. Особенно это касалось одежды, обуви и продуктов питания.

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

Последствия недоверия

Этот скепсис имел долгосрочные последствия. Даже в 2010 году, когда мировой e-commerce уже переживал бум, Россия заметно отставала по темпам роста онлайн-торговли. Потребовалось почти десятилетие (до 2012-2014 годов), чтобы российские потребители массово преодолели этот психологический барьер.

Социальный контекст: как e-commerce менял потребительские привычки

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

Глобальные изменения: от бизнеса к массовому потреблению

В западных странах 2001 год стал переломным для деловых онлайн-транзакций. Система SABRE, разработанная IBM еще в 1960-х, к этому времени превратилась в стандарт для бронирования авиабилетов.

Бизнесмены оценили удобство: вместо походов в кассу или звонков менеджерам можно было за пару кликов оформить билет. По данным American Airlines, к 2001 году через SABRE обрабатывалось до 40% всех бронирований в США.

Не менее революционным оказалось влияние eBay. Площадка не просто создала новый рынок — она изменила отношение людей к вещам. Гаражи и чердаки превратились в источники дохода: в 2001 году миллионы пользователей продавали через eBay всё — от старых пластинок до антикварной мебели. Особой популярностью пользовались коллекционные предметы: например, в 2001 году на аукционе за $3 млн был продан один из первых Apple I.

В России процесс адаптации к онлайн-покупкам шел медленнее. Одним из первых массовых сервисов стала доставка пиццы, хотя и с оговорками. Когда «Папа Джонс» запустил онлайн-заказы в 2003 году (на два года позже американского аналога), это вызвало скорее любопытство, чем доверие.

Проблемы возникали на каждом этапе:

• курьеры часто путали адреса из-за неточных карт;
• время доставки могло растягиваться до нескольких часов;
• только 15% заказов оплачивались онлайн (данные компании за 2004 год).

Тем не менее, даже такой опыт постепенно менял отношение. К 2005-му уже пятая часть москвичей в возрасте 20-35 лет хотя бы раз заказывала еду онлайн — небольшой, но значимый прорыв для того времени.

Экономика

В 2001 году мировой оборот электронной коммерции составлял $65 млрд — скромная цифра по сравнению с $4,2 трлн в 2020-м. Рост стал возможен благодаря массовому распространению интернета, развитию платежных систем и доверия к онлайн-транзакциям.

В России ситуация была еще скромнее: объем рынка e-commerce в 2001-м не превышал 1 млрд рублей, тогда как к 2011 году он вырос до 315 млрд руб. Эти цифры отражают не только технологический прогресс, но и изменение потребительских привычек: если в начале 2000-х онлайн-покупки были редкостью, то к 2010-м они стали частью повседневной жизни.

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

В мае 2024 по всему миру разлетелись скриншоты писем от HR с внезапными повышениями зарплат на 40%. Текучка кадров в сфере производства полупроводников выросла с 40% до 53%, и теперь компании дерутся за каждого специалиста.

Масштаб проблемы

169 отраслей пострадали из-за дефицита чипов — от автомобилестроения до бытовой техники. Tesla и Volvo останавливали заводы, цены на подержанные автомобили выросли на 10% за квартал. Даже стиральные машины подорожали из-за недостатка микросхем.

Но настоящая битва кипит в кабинетах бигтехов. США заблокировали экспорт технологий в Китай, Европа запустила программу на €43 миллиарда, а Азия удерживает 77% мирового производства чипов.

Технологическая война изменила ИТ-индустрию навсегда. Компании теперь не могут просто купить больше серверов — приходится искать тех, кто умеет делать софт быстрее и эффективнее. Apple создала собственные M1 и M2, Google разработал TPU, Amazon — процессоры Graviton. Каждый хочет стать независимым от поставок.

Обрушение цепей поставок

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

Мир оказался в заложниках у нескольких азиатских гигантов. Тайвань контролирует 65% мирового рынка чипов, TSMC делает процессоры для Apple, AMD и NVIDIA. Samsung доминирует в производстве памяти и накопителей.

Различные отрасли посыпались, как домино. Время ожидания полупроводников Broadcom выросло до 22 недель против 12 недель в феврале 2020. Автоиндустрия потеряла миллионы машин, дата-центры замедлили расширение, даже PlayStation 5 стали дефицитом.

США первыми объявили технологическую войну. Пошлины уже изменили процессы производства у Nvidia, Intel и AMD. Китай ответил санкциями против Micron Technology.

Ключевые игроки разделились на два лагеря. На стороне США — Intel, NVIDIA, AMD, Qualcomm. Китай развивает SMIC и вкладывает миллиарды в собственные технологии. TSMC и Samsung балансируют между сторонами, строя заводы и в Америке, и в Азии.

Национальные программы превратились в гонку вооружений. CHIPS Act выделил $50 миллиардов на американское производство. Европейская программа нацелена на производство 20% мировых чипов к 2030 году. Китай инвестирует $143 миллиарда в полупроводники.

Гонки в мире чипов

Рынок AI-чипов взлетел в 15 раз за десятилетие. Компании научились делать процессоры умнее, но каждое новое поколение требует больше денег и экспертизы.

Техпроцессы сжимаются в размере. TSMC освоила 3-нанометровый процесс, Samsung догоняет. Каждый нанометр стоит миллиарды инвестиций и годы разработки. Apple M4 имеет Neural Engine в три раза быстрее M1, но производство одного такого чипа требует сотни инженеров.

AI-чипы стали новой золотой жилой. Intel запустила Gaudi 3, который на 50% быстрее NVIDIA H100. NVIDIA ответила платформой Blackwell с 208 миллиардами транзисторов. Qualcomm Cloud AI 100 обошел H100 по энергоэффективности — 227 запросов на ватт против 108.

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

Делать чипы стало сложнее и дороже. Современная фабрика стоит $20 миллиардов, срок окупаемости — 10 лет. Поэтому крупные компании строят собственные решения: Apple создала M-серию, Google — TPU, Amazon — Graviton.

Компании поменяли философию. Вместо покупки большего количества серверов они нанимают инженеров для оптимизации кода. Netflix использует персонализированные рекомендации и алгоритмы ранжирования для оптимизации вычислений. Meta* оптимизировала машинное обучение и уменьшила количество GPU на 40%.

Массовый переход на ARM изменил рынок. Amazon перевела часть ресурсов на собственные процессоры. Microsoft адаптировала Windows под ARM-архитектуру. Даже Intel вынуждена выпускать подобные решения.

Россия также планирует наладить массовое производство 28 нм чипов к 2030 году. Росатом присоединился к разработке нейроморфных процессоров. Сбер тестировал отечественный Эльбрус-8С, но выявил проблемы с памятью и оптимизацией.

*– компания признана в РФ экстремистской и запрещена.

Айтишники в центре шторма

Зарплаты разработчиков взлетели вместе с ценами на чипы. Средняя зарплата embedded-инженера выросла до $153,383, а топовые специалисты получают до $175,000 в год. Performance-инженеры зарабатывают в среднем $100,522, но спрос превышает предложение. Оптимизация под ARM-архитектуру, разработка драйверов для AI-ускорителей, программирование FPGA — навыки, за которые компании готовы переплачивать. IT-зарплаты в Северной Америке выросли в среднем до $113,211.

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

География возможностей сместилась. Калифорния лидирует по зарплатам — $126,707 в Сан-Хосе, но спрос есть везде. Даже компании из Техаса и Флориды переманивают embedded-разработчиков зарплатами в $120,000-150,000.

Системные администраторы, знающие Kubernetes и контейнеризацию, стали дефицитом. Компании переходят на микросервисы и edge-решения — нужны те, кто умеет управлять распределенной инфраструктурой.

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

Свет в конце туннеля

Эксперты расходятся в прогнозах восстановления. CEO Intel Пат Гелсингер ожидал дефицит до 2024 года, но рынок полупроводников уже показал рост на 15,2% в начале года. К 2023-му автоиндустрия в основном восстановилась, глобальное производство автомобилей выросло на 3%.

Новые фабрики меняют географию производства. Intel строит заводы в Аризоне за $20 миллиардов и расширяется в Огайо. TSMC открыла завод в Японии в феврале 2024 и планирует второй к 2027 году. Samsung инвестирует в производство в Техасе.

Европа также входит в игру. European Chips Act нацелен на производство 20% мировых чипов к 2030 году с бюджетом €43 миллиарда. Intel проектирует заводы в Ирландии и Германии, Micron строит завод в Нью-Йорке, а GlobalFoundries расширяется на Мальте.

Будущее отрасли — в диверсификации. Тайвань по-прежнему контролирует 65% производства, но объемы будут снижаться. К 2030 году США планируют удвоить свою долю в мировом производстве чипов.

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

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

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

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

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

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

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

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

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

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

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

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

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

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

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

Главный трек коллектива — Dust on the Wind — звучит подозрительно похоже на классический хит Dust in the Wind группы Kansas. Его послушали более 380 000 раз с момента релиза 20 июня. А сам коллектив вышел в рекомендации Discover Weekly у части пользователей Spotify.

Однако вскоре слушатели на Reddit начали замечать странности:

• Фотография участников выглядит как сгенерированная ИИ;
• *Instagram-аккаунт — наполнен «неестественными» портретами;
• Цитата из Billboard в описании группы на Spotify не подтверждается никакими источниками;
• Имена участников не находятся ни в одном из поисковиков.

Несмотря на это, ни один музыкальный сервис, кроме Deezer, не пометил The Velvet Sundown как ИИ-контент.

Ни Spotify, ни Apple Music, ни Amazon Music не указывают, что перед нами не настоящая группа — у них пока что нет соответствующего функционала.

Deezer уже борется с ИИ-музыкой

Deezer стала первой платформой, которая начала маркировать ИИ-контент, включая треки, созданные с помощью генеративных моделей вроде Suno и Udio.

По данным сервиса, каждый день на платформу заливается более 20 000 ИИ-песен. В апреле 2024 года они составляли 18% всех загруженных треков — против 10% в январе.

Другой популярный ИИ-проект — The Devil Inside, попавший даже в шоу Джона Оливера Last Week Tonight. Его главный трек Bones in the River набрал 1,6 млн прослушиваний на Spotify, при этом не имеет указания авторов.

Только на Deezer он помечен как сгенерированный и приписан венгерскому музыканту Ласло Тамаши.

Почему это важно

Музыкальные сервисы пока не спешат регулировать ИИ-контент, а вопрос об авторском праве на такие треки остается открытым.

Компании вроде Suno и Udio утверждают, что обучение моделей на защищенной музыке попадает под «добросовестное использование» (fair use), но звукозаписывающие лейблы подают в суд.

По словам главы Deezer, ИИ не является «хорошим или плохим» — все зависит от прозрачности и уважения к авторам. Но пока даже самые популярные платформы вроде Spotify и Apple Music не предлагают пользователям ни прозрачности, ни маркировки.

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Причина — уязвимости в канале доставки: коды приходили не напрямую, а через сторонние компании, включая малоизвестную Fink Telecom, с которой сами техногиганты сотрудничать не планировали.

Что произошло

Журналисты выяснили, что часть SMS-сообщений с кодами 2FA доставлялась через Fink Telecom — компанию, которую Google, *Meta и Signal официально не уполномачивали. Эти SMS могли содержать одноразовые коды доступа и другую чувствительную информацию.

*Meta заявила, что напомнила своим партнерам о контрактных обязательствах, а также запретила прямое или косвенное сотрудничество с Fink Telecom.

В Google подтвердили, что не считают SMS безопасным каналом и постепенно отказываются от него в пользу альтернативных способов.

Signal отметила, что в ее приложении реализована дополнительная защита, например, проверка PIN-кода при повторной регистрации, которая минимизирует риски.

Amazon, Snapchat и Tinder не ответили на запросы Bloomberg о комментарии.

Почему это опасно

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

Что делать пользователям

• Использовать аутентификаторы — приложения, генерирующие одноразовые коды прямо на устройстве (например, Google Authenticator или Authy).
• Включать биометрическую защиту и двухфакторную авторизацию через push-уведомления.
• Не полагаться на SMS как на основной метод защиты.

Google уже начала переводить пользователей Gmail на QR-авторизацию при входе в систему, отказавшись от текстовых сообщений.

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

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

Почему Reddit в ярости

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

В иске говорится, что Anthropic начала парсить Reddit как минимум с декабря 2021 года, несмотря на ограничения, прописанные в robots.txt и в пользовательском соглашении, которое запрещает автоматизированный сбор данных и их коммерческое использование без согласия.

Двуличие Anthropic?

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

Более того, в иске Reddit приводит скриншот разговора с самим Claude, в котором ИИ якобы «подтверждает», что обучался на данных Reddit.

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

Чего требует Reddit

Reddit просит суд:

• Обязать Anthropic удалить все данные Reddit из своих систем.
• Остановить коммерческое использование любых моделей, обученных с использованием этих данных (включая Claude).
• Взыскать всю прибыль, полученную за счет использования данных Reddit.
• Компенсировать ущерб Reddit и оплатить все судебные расходы.
• Назначить штрафные санкции за умышленное нарушение.

Что это значит для индустрии

Этот иск — веха в конфликте между генеративным ИИ и интернет-платформами, предоставляющими контент.

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

Если суд удовлетворит требования Reddit, это может привести к массовому пересмотру практик сбора данных и ограничить обучение ИИ на открытых источниках без лицензий. А Claude — один из главных конкурентов ChatGPT — может оказаться под угрозой закрытия.

Контекст

Anthropic — один из самых финансируемых ИИ-стартапов, с инвестициями от Amazon, Google и прочих IT-гигантов. Reddit же недавно вышел на биржу и стремится максимизировать стоимость своих данных.

В условиях ИИ-бума, это дело может стать определяющим в вопросе: кто владеет интернет-контентом и кто имеет право обучать на нем модели.

Благодаря переданному Amazon коду для многопоточной обработки I/O, Valkey добился серьезного прироста производительности.

Что показали тесты

Тесты проводились на AWS-инстансе Graviton4 c8g.2xlarge с 8 виртуальными ядрами. Valkey 8.1.1 продемонстрировал:

• 999,8 тыс SET-запросов в секунду — против 729,4 тыс у Redis;
• +37% к производительности в SET и +16% в GET;
• −30% по задержкам в SET и −60% в GET.

Особенно заметен прирост при увеличении числа I/O-потоков: при шести потоках Valkey выдает 678 тыс SET-запросов/сек против 563 тыс у Redis (при 256 соединениях). А при 400 соединениях — уже 832 тыс.

Как достигли такого результата

Оптимизация прошла не только на уровне кода, но и на уровне системной настройки:

• Сократили количество переключений контекста, выделив два ядра под обработку прерываний.
• Остальные шесть ядер были закреплены за I/O-потоками Redis и Valkey.
• Использовали ethtool и smp_affinity, чтобы точно задать, какие ядра обрабатывают сетевые IRQ.

В итоге система позволила выжать максимум из архитектуры и достичь почти миллиона SET-запросов в секунду.

Вывод

Valkey — больше не просто «альтернатива Redis». Это полноценный, производительный форк с активной поддержкой сообщества и промышленной оптимизацией от крупных игроков вроде Amazon.

И если раньше Valkey рассматривали как запасной аэродром после смены лицензии Redis, то теперь он становится приоритетным выбором для высоконагруженных систем.

Тогда Хоар задался вопросом: почему программисты до сих пор не создали язык, на котором нельзя случайно сломать даже лифт? Так родился Rust — язык с прицелом на безопасность и надежность. Имя он получил в честь жестких выживающих грибов: «переинженеренных, чтобы не умереть».

В чем сила Rust

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

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

В 2009 году Mozilla увидела в Rust перспективу и стала его спонсировать. В 2010 — проект впервые представили публике. А 15 мая 2015 года вышла стабильная версия Rust 1.0.

За 10 лет — из нишевого языка в глобальный инструмент

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

Его официальный пакетный менеджер crates.io вырос с 2000 пакетов до более чем 180 000. Библиотека стандартных функций утроилась. А каждый релиз проверяется на 600 000 публичных проектах.

Rust развивается быстро, но без сбоев: релизы выходят каждые 6 недель, без разрушения обратной совместимости. Уже внесено 246 000 изменений от 6700 контрибьюторов.

Язык, который создает инфраструктуру

Rust не пытается быть всем сразу. Это не замена Python или JavaScript. Rust — язык «труб и фитингов»: он нужен для создания тех самых фундаментальных систем, на которых работает все остальное.

Именно поэтому он стал любимцем среди системных разработчиков. В опросе Stack Overflow язык восьмой год подряд занимает первое место по симпатии: более 80% пользователей хотят продолжать с ним работать.

От Firefox до ядра Linux

Сегодня Rust применяют Google, Microsoft и Amazon. Mozilla внедрила его в Firefox, Google — в Android и ChromeOS, Microsoft — в ядро Windows и облачные сервисы Azure.

Rust даже начал проникать в ядро Linux. Линус Торвальдс признал, что разработчикам непросто учиться новому языку, особенно с таким отличием от привычного C. Но сам он Rust в ядре активно поддерживает.

Учиться сложно, но оно того стоит

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

Среди лучших источников — The Rust Programming Language (в народе просто «The Book»), Rust for Rustaceans и бесплатные онлайн-курсы Rust by Example и Comprehensive Rust от Google.

Главное — не язык, а сообщество

По словам самого Хоара, Rust — это не только о коде. Это история о большом сообществе, которое объединилось ради создания надежной технической основы для будущего. Он называет Rust «языком для создания инфраструктуры» — и в этом его миссия.

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

По крайней мере, так говорят зарубежные компании, когда называют массовые сокращения айтишников оптимизацией. Сценарий стандартный: бизнес автоматизирует процессы, алгоритмы берут на себя часть задач, а 300–400 мидлов остаются без работы.

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

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

Что случилось с рынком: цифры, которые пугают

2024 год стал точкой невозврата для IT-индустрии. Компании, зарубежные и российские, которые ещё вчера нанимали разработчиков сотнями, сегодня объявляют о сокращениях.

CNews написали, что некоторые отечественные компании хотят сократить как минимум 30% айтишников, а в отдельных случаях — до половины штата. Про ИИ в заявлениях ни слова, но люди всё равно переживают. В Твиттере, на Пикабу и Хабре всё больше обсуждают, как быстро нас всех заменит ИИ и кто будет первым: фронтендеры, копирайтеры или техподдержка?

В США ситуация тоже непростая: доля безработных айтишников выросла с 3,9 до 5,7% всего за один месяц. Но в отличие от наших компаний западный бизнес иногда признаётся, что сократил сотни человек из-за ИИ.

В начале этого года IBM начала мягкие увольнения в области финансов через требования переехать ближе к хабам компании. Параллельно компания внедряет ИИ-технологии в операционку и заменяет ими реальных людей. В PayPal уволили около 9% сотрудников, а за несколько дней до этого запустили проект с ИИ. Не выглядит как совпадение.

На фоне этого акции Meta *, Google и NVIDIA бьют рекорды — инвесторы надеются на «революцию ИИ».

Лирическое отступление: что думают люди

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

Другое мнение — скоро нас всех уволят из-за ИИ, потому что нейросети уже могут создать веб-приложение, настроить сервер и помочь подключить Wi-Fi.

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

Почему компании увольняют IT-специалистов

Во время ковида рынок IT-специалистов резко вырос: компании массово нанимали людей, чтобы поддерживать цифровизацию, онлайн-сервисы и удалённую работу. Сейчас спрос стабилизировался, и перенасыщение рынка привело к закономерным увольнениям. Но это одна из причин.

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

Некоторые уже заменили часть команды на искусственный интеллект:

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

Порассуждаем, какую выгоду ИИ приносит бизнесу.

Помогает с рутиной

Copilot помогает писать код и проверяет его на ошибки, ChatGPT генерирует сценарии для тестирования, а Claude вдохновляет на новые идеи для масштабирования приложения. Раньше у разработчиков была IDE и документация, а теперь — целый набор разных нейросеток. И они действительно работают.

Anketolog.ru и Mediacom.Expert опросили 1 100 представителей ИТ-сферы. 57% опрошенных считают, что именно автоматизация рутины — главный плюс ИИ. А 53% специалистов назвали ключевым преимуществом нейросетей увеличение продуктивности.

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

Снижает расходы

Бизнес ищет способы снизить затраты, и один из них — внедрить ИИ. По данным исследования Стэнфорда, 42% компаний подтвердили, что нейросети помогли сократить расходы.

Например, Walmart посчитал, что ИИ на 10% увеличил продажи и на 20% сократил излишки закупок. А исполнительный директор Klarna, шведской финтех-компании, заявила, что их ИИ-ассистент уже может с лёгкостью заменить труд 700 специалистов техподдержки.

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

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

Выгодно ли это на самом деле

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

(Не)дешёвый код

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

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

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

Деградация экспертности

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

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

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

Разочарование акционеров

Искусственный интеллект — это не только тренд, развлечение и инструмент для работы, но и новое золото для акционеров.

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

На Reddit можно прочитать историю контент-мейкера, которого решили заменить с помощью ChatGPT и нескольких джуниор-копирайтеров. Через две недели его попросили вернуться, но парень отказался.

И скорее всего, это не разовая акция. Кстати, об акциях. Вопрос окупаемости ИИ волнует не только компании, но и инвесторов.

Goldman Sachs в своём отчёте задались логичным вопросом: в ИИ вложили около триллиона долларов — а что на выходе? Пока что главное достижение — разработчикам стало работать проще. Ну и в соцсетях можно посмотреть на Марка Цукерберга, неожиданно заговорившего по-русски.

Аналитик Джим Ковелло в этом отчёте предполагает, что эта сумма так никогда и не окупится: нет таких дорогих задач, которые под силу искусственному интеллекту.

Прав ли он? Время покажет.

ИИ без базы знаний — деньги на ветер

Даже самый продвинутый ИИ бесполезен, если «кормить» его устаревшими материалами. Это приведёт к ошибкам и некачественному коду. А дальше — убытки, репутационные риски и ещё раз убытки.

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

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

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

Дыры в безопасности

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

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

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

Но не все так осторожны. В 2023 году сотрудники Samsung трижды (!) поделились с ChatGPT исходным кодом компании, из-за чего этот код добавился в базу для обучения нейросети. Это произошло случайно: работники Samsung просто не знали, как именно работает ИИ-чат. Судя по всему, к каким-то критичным последствиям это не привело. Но это скорее везение.

Чем компании могут заменить массовые увольнения

Сокращения неизбежны, потому что ИИ может выполнять простые задачи намного лучше нас. Да и рынку не нужно такое количество IT-специалистов, как раньше.

Бум диджитализации закончился, и даже Марк Цукерберг постепенно сокращает штат. К концу пандемии в Meta * было 87 000 специалистов. Но уже в 2023 году он уволил 10 тысяч человек, а в начале 2025-го — ещё 5%, примерно 3 600 сотрудников.

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

Переформатировать, а не сокращать

Компании могут сохранить команду и перераспределить ресурсы:

1. Переобучить сотрудников. Например, IBM в 2020–2023 годах инвестировала 1 млрд долларов в переподготовку своих специалистов для работы с ИИ.
2. Создать новые роли. Вместе с ИИ появились и новые профессии — промпт-инженеры и ИИ-тренеры. Это направление уже осваивают Microsoft, Google и российский «Яндекс».
3. Построить гибридные рабочие модели. Переключать членов команды на задачи, где нужен человеческий опыт: креатив, стратегия, коммуникация с клиентами. А рутину оставить искусственному интеллекту.
4. Учесть риски и преимущества ИИ. Маленьким компаниям стоит проводить «ИИфикацию» только в том случае, если искусственный интеллект действительно принесёт пользу. Потому что есть риск, что вы больше потратите, чем сэкономите. Интеграция нейросетей в бизнес-процессы может стоить недёшево.

Внедрять ИИ осмысленно

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

1. Можно начать с малого, например, автоматизировать техподдержку, и проверить, не просядет ли качество.
2. Считать расходы правильно — учитывать не только зарплаты, но и затраты на платформы, ML-инженеров и доработки, которые вносятся в сгенерированный нейросетью результат.
3. Стоит отдавать предпочтение закрытым и безопасным ИИ-моделям, чтобы не сливать данные конкурентам и не подводить своих клиентов, выдав их личную информацию злоумышленникам.
4. Обучать ИИ только на проверенных данных. Это снижает риск ошибок и «галлюцинаций» модели.

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

Чтобы решить эту проблему, бизнес внедряет системы управления знаниями, которые помогают не только команде, но и ИИ. Например, в Minerva Knowledge можно объединить знания всей компании: создать статьи и инструкции, загрузить любые документы и файлы, а потом легко найти их с помощью умного поиска.

А ассистент с генеративным ИИ сам анализирует контекст и подсказывает ответы на основе материалов из базы знаний.

Для айтишников: в какую сторону двигаться

Уже поздно делать вид, что ИИ — это несерьёзно и скоро о нём все забудут. Поэтому в такой ситуации можно приспособиться к изменениям.

• Дружба с ИИ. Можно использовать ИИ-помощников в работе, но с проверкой их ответов.
  
• Автоматизация рутины. Можно поручить ИИ тестирование, документацию, деплой, чтобы тем самым освободить время для задач, где нужна экспертность.
• Изучение промпт-инжиниринга. Очень важно точно формулировать запросы к ИИ, чтобы он смог дать качественный ответ. Советы можно посмотреть в гайдах от OpenAI.

• Анализ рынка. Можно изучить вакансии — например, AI-тренера и промпт-инженера. Вдруг вас заинтересует сфера ИИ и нужно будет начинать карьеру с джуновских вакансий.

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

Некоторые веб-разработчики уже всерьёз задумались, не стоит ли перейти в эту область.

ML-специалисты получают больше веб-разработчиков, теперь это новый тренд в ИТ

Подытожим.

• ИИ — не враг, а инструмент, и те, кто научится им управлять, получат преимущество, так как смогут подкреплять свою экспертность знаниями нейросетей.
• Бизнесу не стоит экономить на сотрудниках, а стоит начать инвестировать в их переобучение.
• Разработчикам следует воспринимать ИИ как второго пилота — толкового, но требующего контроля.

Что будет дальше — увидим уже очень скоро. А пока что в IT есть место и людям, и нейросетям.

*Компания Meta признана экстремистской на территории РФ

Вместе с Александром Душеиным, архитектором Yandex Cloud, в статье мы рассмотрим современные подходы к защите данных через технологии OS Login, сервисы метаданных и федерацию аккаунтов. Поделимся практическими приёмами настройки шифрования и методами автоматизации работы через группы виртуальных машин.

Байка о Сергее и Кевине

Все персонажи вымышленные, ни один сисадмин не пострадал.

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

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

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

Мораль: не храните пароли в открытом виде, а ещё лучше не храните их совсем. Это может сыграть злую шутку, даже если данные не попадут к злоумышленникам.

Полностью отказаться от хранения паролей помогут современные облачные технологии, такие как OS Login.

Забудьте про рутину с SSH-ключами

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

OS Login решает эту проблему — он связывает учётную запись в Linux с облачной учётной записью. Больше не нужно вручную добавлять SSH-ключи в ~/.ssh/authorized_keys на каждой ВМ. Теперь они привязываются к IAM-пользователю или сервисному аккаунту, а доступом можно управлять через IAM-политики.

В Google Cloud достаточно включить OS Login на уровне проекта или организации и назначить пользователю роль roles/compute.osAdminLogin. После этого он получает доступ ко всем нужным ВМ. В Yandex Cloud механизм работает похожим образом — доступ привязывается к облачному аккаунту организации.

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

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

Паролефобия: почему лучший пароль тот, которого нет

Пароли, сертификаты, токены доступа, API-ключи — для работы сервисов и конвейеров (CI, CD, AirFlow и т.д.) необходимо множество секретов для доступа к различным системам и данным: container registry, базам данных, кластерам Kubernetes и другим. Для безопасного хранения учётных данных существуют специализированные сервисы и утилиты, но для доступа к ним внезапно требуются... ключи, сертификаты, пароли. Можно ли обойтись без них?

В облаке ответ — да. Вместо хранения статических паролей можно использовать более надёжные способы. OS Login избавляет от необходимости создавать отдельные пароли для каждой ВМ. SSO помогает забыть о локальных учётных записях на серверах — достаточно корпоративной. А временные токены (Security Token Service, STS) позволяют отказаться от «вечных» ключей доступа, которые так любят утекать в публичные репозитории.

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

Сервис метаданных: полезный инструмент с подвохом

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

История взлома Capital One наглядно показывает риски: злоумышленник может провести SSRF-атаку и заставить сервер обратиться к метаданным. В результате он получит доступ к IAM-токенам. Облачные провайдеры решают эту проблему по-разному. AWS требует получить специальный токен в IMDSv2. Google Cloud использует обязательный заголовок «Metadata-Flavor: Google». А Yandex Cloud и вовсе отключил поддержку IMDSv1 из-за рисков безопасности.

Для предотвращения компрометации инфраструктуры через SSRF-уязвимости разработчикам необходимо соблюдать следующие правила:

• Не храните секреты в пользовательских метаданных;
• Ограничивайте доступ к сервису для контейнеров, которым не требуются токены;
• Учитывайте, что сервис метаданных будет доступен и для контейнеров, запущенных на хосте;
• Используйте файерволл операционной системы или network policy в Kubernetes для ограничения доступа к сервису метаданных.

Федерация сервисных аккаунтов: внешние сервисы становятся своими

Представьте: у вас есть под Kubernetes, которому нужен доступ к секрету в Yandex Lockbox. Или CI/CD система вроде GitLab должна развернуть облачные сервисы через Terraform. Обычно в таких случаях создают сервисный аккаунт со статическим ключом. Но у этого подхода есть проблемы: ключи утекают в Git-репозитории, а их ротация превращается в квест.

Workload Identity Federation (федерация сервисных аккаунтов) предлагает элегантное решение: внешний сервис использует свой токен аутентификации для обмена на временные облачные креденшелы. Каждый провайдер реализует это по-своему:

• AWS использует IRSA (IAM Roles for Service Accounts) — под в Kubernetes получает JWT-токен и обменивает его на временные IAM-креденшелы;
• Azure через Microsoft Entra ID проверяет OIDC-токены от GitHub Actions или Kubernetes;
• Yandex Cloud позволяет обменять OIDC-токен от совместимого провайдера на IAM-токен сервисного аккаунта.

Защита данных: шифруем всё

Объектные хранилища вроде AWS S3 стали настоящей головной болью для специалистов по безопасности. Достаточно поискать в интернете «S3 bucket leak», чтобы понять масштаб проблемы. Первая линия защиты — временные ключи (Security Token Service, STS). Даже если их скомпрометируют, время жизни ограничено, а значит и потенциальный ущерб минимален.

Но что если злоумышленник получит физический доступ к носителю или бэкапу? Здесь поможет только шифрование данных. AWS, GCP и Yandex Cloud предлагают шифрованные диски на базе алгоритма AES-256 с управлением ключами через KMS-сервисы.

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

Но даже если вы зашифровали все данные и настроили безопасный доступ, остаётся важный вопрос: кто и что делает в вашем облаке? Помните историю про Сергея и Кевина? А что если злоумышленник всё-таки получит доступ к вашим ресурсам или кто-то из сотрудников решит «немного» превысить свои полномочия?

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

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

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

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

Прозрачность и управляемость: предупреждён — значит вооружён

Проинформировать ВМ о предстоящих важных событиях и дать возможность приготовиться — вот задача сервисов мониторинга облачных провайдеров. Каждый решает её по-своему:

• AWS уведомляет о Scheduled Events через AWS Health Dashboard;
• Google Cloud использует Live Migration, предупреждая о перемещении ВМ за 60 секунд;
• Yandex Cloud через Политики обслуживания ВМ позволяет выбрать сценарий (migrate или restart) и отложить обслуживание.

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

Облачные провайдеры позволяют менять конфигурацию на лету. Закончилось место на диске посреди важного расчёта? Можно увеличить его объём без остановки ВМ. Хотите проверить отказоустойчивость вашего сервиса? Отключите сетевой интерфейс на ходу, имитируя сбой сети, а затем подключите его обратно — всё это без перезагрузки машины.

Готовитесь к росту нагрузки, но переделывать приложение для Kubernetes не видите смысла? Вам помогут группы виртуальных машин:

• В Yandex Cloud можно создать группу с фиксированным числом машин или настроить автоматическое масштабирование по метрикам (CPU, память, очереди и т.д.);
• AWS Auto Scaling Groups и Google Managed Instance Groups работают похожим образом: добавляют мощности при росте нагрузки и убирают лишнее при снижении;
• Гибкое управление конфигурацией через систему переменных позволяет, например, выделять IP-адреса из заранее зарезервированного пула;
• Если ВМ выходит из строя, группа автоматически заменит её, а балансировщик уберёт сбойный экземпляр из ротации.

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

Безопасность vs удобство: как найти баланс

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

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

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

Больше про облака и другие важные IT-инструменты — в нашем тг-канале

Хаос необходимо упорядочить — и тут на помощь приходит As Code. Это не просто методология, а философия, где все — от инфраструктуры до документации и политик безопасности — становится кодом. В этой статье я расскажу, почему подход As Code стал критически важен для современных IT-компаний и как он эволюционировал.

С чего все началось

На одном митапе по стандарту разработки нам с Head of Profession задали вопросы, которые зависли в воздухе, как нерешенный баг в коде: «А что за потребность все делать с помощью As Code? Какая от этого польза? Зачем число коммитящих в код?»

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure as Code, API First, unit-тесты, компонентное тестирование, TBD (Trunk Based Development), GitOps, Doc As Cod. Мы дорабатываем пайплайны, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояния в другое.

Каждый коммит — шаг в будущее, где код становится не просто текстом, а нитью в живой ткани новой реальности. Число коммитящих — это не просто метрика, это сигнал, что система жива, дышит, развивается. И когда кто-то спрашивает «Зачем?», я отвечаю: «Потому что иначе мы останемся в прошлом, где ручные процессы, как старые провода, тянут нас назад в тишину, замедляя каждый шаг. Мы строим мир, где As Code не просто слова, код — наша новая реальность. И каждый, кто коммитит, становится частью этой вселенной».

В момент осознания вопроса я провалился на другой слой реальности, задумался об истории As Code и собрал этот текст из разбросанных по сети слепков. Эта статья — не руководство по Terraform или Kubernetes, а скорее практический взгляд на культуру As Code в масштабах крупной IT-компании.

Эволюция As Code: от истоков до современности

Концепция As Code возникла как ответ на ключевые вызовы IT-индустрии: рост сложности систем и ускорение темпов изменений. Она был естественным продолжением эволюции разработки — код стал не только инструментом создания программ, но и способом управления инфраструктурой, документацией, архитектурой и политиками.

У появления этого подхода было несколько предпосылок:

1. Автоматизация и стандартизация. В 1990-х годах с развитием DevOps и agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Новые задачи стали основой для появления подходов, где все описывается в виде кода.
2. Распространение систем контроля версий. В 2005 году появился Git, который стал инструментом для управления изменениями, что позволило хранить и версионировать не только код, но и документацию, конфигурации и архитектуры.

Корнями As Code уходит в 1970-е годы. Ранние инструменты, такие как Unix “Make” и PXE boot, заложили фундамент для автоматизации конфигураций. Позже они эволюционировали в современные подходы: Infrastructure as Code, Documentation as Code, GitOps и другие. Это подчеркивает, что As Code — не просто тренд, а естественное развитие технологий, которое упрощает управление сложными системами.

Почему все теперь в Git?

С развитием подхода As Code универсальным инструментом управления изменениями стал Git. Это произошло благодаря нескольким ключевым причинам.

• История изменений: Git хранит всю историю изменений, что позволяет отслеживать, кто, когда и что делал. Это критически важно для анализа и отката ошибок.
• Коллаборация: над проектом может работать несколько человек, и они не будут мешать друг другу.
• Прозрачность: все изменения видны, их можно обсудить, проверить и улучшить через механизмы pull/merge requests.
• Автоматизация: Git интегрируется с CI/CD — Continuous Integration / Continuous Deployment. Это позволяет автоматизировать тестирование, сборку и деплой. Работа в Git позволяет «все иметь под рукой» и упрощает создание систем поддержки и контроль стандартов ИТ-производства.
• Безопасность: Git позволяет контролировать доступ к коду и данным через ролевую модель и механизмы проверки изменений.

Как появился Git?

Git был создан в 2005 году как ответ на кризис в разработке ядра Linux. Ранее команда Linux использовала проприетарную систему контроля версий BitKeeper, но юридические споры лишили программистов этой возможности. Linux-сообщество осталось без инструмента для управления кодом. Существующие системы — например, CVS или Subversion — не подходили для масштабных проектов.

Линус Торвальдс, создатель Linux, решил разработать собственную систему, которая бы отвечала потребностям крупных проектов:

• была быстрой,
• поддерживала распределенную разработку,
• гарантировала сохранность данных (через хеши SHA-1).

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

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

Эволюция Git:

• 2005: первый релиз Git;
• 2008: появление GitHub, который популяризировал Git среди разработчиков;
• Сейчас: Git де-факто стал стандартом для контроля версий, который используют разработчики по всему миру.

Основные подходы As Code

Infrastructure as Code (IaC)

IaC — это описание в виде кода инфраструктуры: серверов, сети баз данных. Например, с помощью Terraform, Ansible, CloudFormation. Инструмент позволяет сделать инфраструктуру воспроизводимой, предсказуемой и легко управляемой. Вместо ручного создания серверов в облаке вы можете описать их в коде и развернуть одной командой.

Когда мы слышим термин Infrastructure as Code, то обычно думаем о современных инструментах, таких как Chef, Ansible или Terraform. Однако сама идея управления инфраструктурой и конфигурациями через код уходит корнями в 1970-е годы. Уже тогда инженеры сталкивались с необходимостью автоматизировать управление парками машин, будь то физические или виртуальные системы.

Одним из первых инструментов, позволявших автоматизировать сборку и настройку программного обеспечения, был Unix “Make” (1976). Хотя Make не стал полноценным инструментом управления инфраструктурой, он заложил основы для автоматизации задач конфигурации. Следующим важным шагом к автоматизации стал PXE boot (1981). Он позволял загружать и настраивать по сети целые машины — это стало прообразом современных подходов к управлению инфраструктурой.

Хотя эти ранние инструменты не считаются полноценными решениями для управления инфраструктурой, они создали основу для современных подходов. Unix “Make” и PXE boot показали, что автоматизация конфигураций возможна и необходима, особенно с ростом сложности систем.

Как дальше складывалась эволюция IaC:

• 1990-е: следующий этап развития начался с появлением CFEngine (1993). Это был один из первых инструментов, позволявших управлять конфигурациями на множестве машин.
• 2000-е: с развитием облачных технологий и DevOps появились более мощные инструменты, такие как Puppet (2005) и Chef (2009). Они сделали управление через код отраслевым стандартом. 2010-е: Ansible (2012) и Terraform (2014) стали лидерами в области IaC. Они предложили более гибкие и мощные решения для управления облачной инфраструктурой.
• 2013: появился Docker, который произвел революцию в контейнеризации. Он обеспечил легкость в создании, развертывании и масштабировании приложений, а также упростил процессы управления инфраструктурой.
• 2014: Kubernetes предложил автоматизацию развертывания, масштабирования и управления контейнизированными приложениями.
• 2017: создан Pulumi, который позволил управлять ресурсами облачной инфраструктуры с использованием таких языков программирования, как Go, JavaScript, TypeScript, Python, Java, C# и YAML. Благодаря этому инструменту разработчики смогли быстрее интегрировать IaC в свои процессы и создавать более сложные сценарии для автоматизации.
• 2021: появился Brainboard, который значительно упростил разработку, визуализацию и управление инфраструктурой как кодом. Он предложил графический интерфейс для создания и изменения архитектуры облаков. Это помогло сделать IaC доступным не только для разработчиков, но и для более широкого круга пользователей, в том числе для аналитиков и проектировщиков.

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

Documentation as Code (Docs as Code)

Подход Docs as Code позволяет разрабатывать техническую документацию с помощью тех же инструментов, что и код. Документы создаются в формате, который легко версионировать и хранить в Git, — например, Markdown или AsciiDoc. Это дает значительные преимущества:

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

Подход Docs as Code начал развиваться в 2000-х годах. В это время крупные компании, такие как Microsoft, начали использовать внутренние инструменты для генерации документации из исходного кода. Например, документация .NET Framework уже создавалась с помощью автоматизированных процессов.

В 2010-х годах термин Docs as Code был популяризирован. Тогда такие инструменты, как Markdown, AsciiDoc и Sphinx, стали широко использовать для создания и управления документацией в репозиториях Git.

Architecture as Code (AaC)

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

Подход Architecture as Code начал развиваться в 2010-х годах с появлением Structurizr (2014) и других инструментов. Сегодня AaC используют для описания в формате, который можно версионировать и тестировать. Например, C4-модель помогает разработчикам и архитекторам лучше понимать сложные системы.

Хотя конкретные компании редко публично афишируют использование C4-модели или Aac, есть несколько примеров, где эти подходы активно применяются.

Крупные технологические компании

• Microsoft использует C4-модель, чтобы документировать архитектуры своих облачных сервисов, таких как, допустим, Azure. Подход AaC помогает автоматизировать создание диаграмм и поддерживать документацию в актуальном состоянии.
• Внутренние команды Amazon Web Services используют C4-модели для описания архитектуры своих сервисов, а инструменты AaC помогают интегрировать эти описания в CI/CD-процессы.

Финансовые организации

Многие банки и финтех-компании используют C4-модели, чтобы документировать сложные распределенные системы. Например, ING и Goldman Sachs применяют AaC для автоматизации создания архитектурных диаграмм и проверки соответствия стандартам.

Консалтинговые и IT-компании

• Разработчик и поставщик программного обеспечения ThoughtWorks активно продвигает использование C4-модели и подхода Architecture as Code в своих проектах. Компания создает инструменты и практики для интеграции AaC в процессы разработки.
• Производитель программного обеспечения Red Hat использует C4-модели для документирования архитектуры своих решений, таких как OpenShift, и применяет AaC для автоматизации создания диаграмм.
• Также активно использует и применяет C4-модели X5 Tech — основной цифровой партнер торговых сетей и бизнесов X5 Group.

Policy as Code

Этот подход позволяет описывать политики и управлять ими, например безопасностью или доступом. Policy as Code дает возможность автоматизировать проверку на всех этапах жизненного цикла ПО и обеспечить compliance — соответствие требованиям.

Подход Policy as Code стал популярным с появлением таких инструментов, как Open Policy Agent (OPA) и Hashicorp Sentinel. Они позволили описывать политики безопасности и compliance в виде кода, что стало особенно востребованным в облачных средах.

GitOps

GitOps — подход, в котором Git становится единым источником истины для управления инфраструктурой и приложениями. Они описываются в коде — например, с помощью Kubernetes manifests — а все изменения автоматически применяются через CI/CD.

Концепцию GitOps в 2017 году формализовала компания Weaveworks, этот подход дает несколько преимуществ:

• прозрачность — все изменения видны в Git;
• автоматизация — процессы деплоя и обновления автоматизированы;
• безопасность — изменения проходят код-ревью и тестирование.

GitSecOps

GitSecOps — расширение GitOps с акцентом на безопасность, которое стало развиваться в 2020-х годах. С помощью этого инструмента можно интегрировать безопасность в процесс разработки и эксплуатации через код, он позволяет внедрить в CI/CD инструменты статического анализа кода (SAST) и анализа зависимостей (SCA).

Преимущества этого подхода:

• раннее выявление уязвимостей;
• автоматизация проверок безопасности;
• соответствие стандартам — например, GDPR или HIPAA.

Будущее с As Code

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

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

Footnotes:

• Everything as Code Explained

• Write the Docs Guide: Docs as Code

• Understanding Docs as Code

• The Origins of Infrastructure as Code

• Canary Deployment Strategies

• AWS Whitepaper: Blue-Green Deployments

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

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

Почему Google передумала?

Официальная версия — меняется мир, а с ним и подход к ИИ. Глава Google DeepMind Демис Хассабис и топ-менеджер Джеймс Маника объяснили в блоге:

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

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

Что об этом думают сотрудники?

Многие недовольны. Их не спросили, а решение приняло руководство. В 2018 году сотрудники уже протестовали против контракта Google с Пентагоном. Тогда компания отказалась от военных проектов и написала принципы этичного ИИ.

Теперь они пересмотрены. Google не скрывает, что хочет работать с государством. Особенно на фоне того, что конкуренты — Microsoft, Amazon, OpenAI, Anthropic — уже сотрудничают с военными.

Что это значит?

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

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

Но вопрос остается: сможет ли Google сохранить баланс между бизнесом, этикой и ожиданиями пользователей?

Он признался, что прошлое «я» спорило бы с ним по каждому из этих пунктов.

Что теперь кажется очевидным

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

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

С годами изменился и взгляд на Java. То, что раньше казалось скучным, теперь воспринимается как главное достоинство языка. «Java — отличный язык, потому что он скучный», — отметил Крис.

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

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

Изменение взглядов на инструменты и подходы

С годами пришло понимание, что эстетическая элегантность кода не важна. Главное — понятность и поддерживаемость.

Ранее он считал, что ORM (объектно-реляционные мапперы) полезны, но теперь уверен, что они — зло. Он рекомендует просто писать SQL, а не полагаться на промежуточные слои.

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

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

Что осталось неизменным

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

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

Также он уверен, что большинство проектов не нуждаются в масштабируемости, но разработчики слишком часто ведут себя так, будто работают на уровне AWS.

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

Всё больше пользователей отдают предпочтение альтернативам на основе искусственного интеллекта, таким как ChatGPT, Perplexity и т.д.

Эти платформы способны давать точные и быстрые ответы без необходимости искать информацию самостоятельно.

Почему Google теряет популярность?

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

По данным исследований, 23% пользователей TikTok начинают поиск информации в приложении в первые 30 секунд после его открытия. Общий объём поисковых запросов на платформе составляет около 3 млрд в день.

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

Проблемы самой экосистемы Google

Одной из ключевых угроз для Google является рост количества контента, созданного ИИ, что ухудшает качество поисковых результатов.

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

Угрозы для бизнеса Google

По прогнозам eMarketer, в 2025 году доля Google на рынке поисковой рекламы в США впервые упадёт ниже 50%. Основные конкуренты, такие как Amazon и TikTok, активно привлекают рекламодателей, предлагая новые форматы взаимодействия с аудиторией.

В то же время, недавнее судебное разбирательство Министерства юстиции США по делу о монополизации может ещё больше подорвать позиции Google. Среди предложений — продажа браузера Chrome и ограничение привилегий Google Search на Android-устройствах.

Особое внимание будет уделено функциям, использующим ключевое слово unsafe, которое допускает небезопасные операции с памятью. Сейчас таких функций насчитывается около 7500 из 35 000 функций библиотеки.

Почему это важно

Несмотря на высокую репутацию Rust как безопасного языка программирования, блоки unsafe позволяют выполнять критические операции, такие как разыменование указателей или вызов библиотек на C/C++, что создаёт потенциальные риски.

За последние три года было выявлено 57 проблем в стандартной библиотеке, 20 из которых классифицированы как уязвимости.

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

Как будет организована работа

Проект реализуется в формате конкурса.

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

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

Например, одна из задач предполагает анализ работы с raw-указателями в модуле core::ptr. Участникам предлагается использовать существующие инструменты, такие как Aeneas, Kani, Verus и Creusot, или предложить собственные подходы.

Что дальше

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

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

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

AWS EC2 (Elastic Compute Cloud)

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

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

AWS Fargate

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

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

Ключевые различия

• Управление: EC2 требует ручного управления серверами, тогда как Fargate автоматизирует этот процесс.
• Масштабирование: Fargate автоматически масштабирует ресурсы, в то время как в EC2 масштабирование необходимо настраивать вручную.
• Контроль: EC2 предоставляет полный контроль над инфраструктурой, что может быть критически важным для специфических приложений. Fargate же ограничивает возможности настройки, предлагая более стандартизированный подход.
• Стоимость: Fargate может быть более экономичным для небольших и средних нагрузок благодаря оплате только за используемые ресурсы. Однако при больших и постоянных нагрузках EC2 может оказаться более выгодным.

Выбор между EC2 и Fargate

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

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

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

В то же время оригинальные модели можно безопасно приобрести только в проверенных магазинах, например, Amazon, Newegg, BestBuy или Microcenter.

Признаки подделки: на что обращать внимание

Фейковые Ryzen 7 9800X3D легко распознать по нескольким признакам.

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

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

Более того, мошенники часто используют старые упаковки, отличающиеся формой: оригинальный Ryzen 7 9800X3D поставляется в прямоугольной коробке, тогда как подделки зачастую упакованы в квадратные.

Опасности покупки с рук

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

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

Если что-то вызывает сомнения, лучше отказаться от покупки.

Компания Elastic объявила о добавлении лицензии AGPL в качестве опции наряду с существующими ELv2 и SSPL.

Этот шаг позволяет использовать термин «Open Source» в соответствии с определением OSI (Open Source Initiative), что вызвало большую радость как минимум у самой команды Elastic.

История изменений лицензии

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

Это изменение вызвало значительные дискуссии в сообществе и многие обвинили Elastic в отходе от принципов Open Source.

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

Возвращение к истокам

Теперь, когда ситуация на рынке стабилизировалась, Elastic решила вернуть Elasticsearch статус Open Source, добавив AGPL в качестве одной из лицензий.

AGPL — это лицензия, одобренная OSI и широко используемая в таких проектах, как MongoDB и Grafana.

Что дальше?

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

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

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

Ошибка #1: То, что привело вас сюда, не поднимет вас выше

В 2016 году, находясь в середине восьмилетнего пути к следующему уровню в карьере, автор статьи решил сосредоточиться на продвижении.

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

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

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

Ошибка #2: Промоушн-донат

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

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

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

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

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

Ошибка #3: Ваш менеджер важнее, чем ваши способности

Между 2015 и 2019 годами автор статьи работал под руководством пяти разных менеджеров, и один из них оказался настоящим кошмаром.

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

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

Автор осознал, что менеджер играет ключевую роль в процессе продвижения. Хороший менеджер не только поддерживает и направляет, но и помогает планировать шаги для достижения следующего уровня.

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

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

При этом Гарман подчеркнул, что ИИ не заменит разработчиков, а наоборот, откроет перед ними новые возможности.

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

Как ИИ изменит профессию программиста?

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

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

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

Взгляд в будущее

Гарман также призвал сотрудников Amazon искать новые способы интеграции ИИ в свои рабочие процессы.

Подобные прогнозы разделяют и другие лидеры в IT-индустрии. Например, глава NVIDIA Дженсен Хуанг считает, что благодаря ИИ каждый человек сможет стать программистом.

Бывший CEO Stability AI Эмад Мостака прогнозирует, что через пять лет программистов как таковых больше не будет.

В ходе работы над этим проектом они обнаружили способ сэкономить $5000 в месяц, снизив время запуска подов на 300 мс.

Переход на Kubernetes

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

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

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

Оптимизация AWS SDK

Первым шагом команды было уменьшение размера контейнеров, используя модульную версию AWS SDK (версия 3).

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

Использование логов и Grafana

Для определения точного источника проблемы разработчики добавили логирование времени готовности подов.

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

Используя Grafana Loki и LogQL, команда смогла обрабатывать неструктурированные логи как метрики, что позволило точнее определить, какие модули замедляют запуск.

Необычный трюк

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

Изменив версии всех модулей на одну и ту же, они значительно сократили время запуска подов. Этот простой шаг привел к сокращению времени запуска подов примерно на 300 мс.

Экономия средств

После внедрения изменений, команда увидела значительное сокращение числа используемых подов, что привело к экономии примерно $5.5 тыс в месяц.

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

Об этом стало известно благодаря инсайдерам, поделившимся сообщениями из Slack IT-гиганта.

Массовые увольнения и экономия

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

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

Реакция работников компании

«Наконец-то стремление стать лучшим работодателем на Земле (для L8+)», — написал один из сотрудников, иронично указывая на один из последних принципов лидерства Amazon, обещающий создать более безопасную и продуктивную рабочую среду.

Многие работники Amazon жалуются на отсутствие бюджета даже на ежемесячные мероприятия для своих команд.

Отметим, что на данный момент представители компании не предоставили комментариев по поводу произошедшего.

Он рассказал, как сервис разработал систему деплоя, которая минимизирует время простоя до менее 4 минут в месяц. В этом процессе ключевую роль играют несколько факторов.

Контейнеризация

AWS использует контейнеры для управления приложениями. Сервисы, такие как Amazon Elastic Container Service (ECS), позволяют запускать и управлять контейнерами, обеспечивая высокую степень автоматизации и масштабируемости.

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

Автоматизация процессов

Автоматизация является важным элементом, позволяющим минимизировать время простоя. AWS использует инструменты автоматизации, такие как Terraform, для управления инфраструктурой.

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

Стратегии деплоя

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

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

Оптимизация производительности

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

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

Безопасность и соответствие стандартам

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

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

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

AWS и GoDaddy не выполнили это требование, за что и получили блокировку своих сайтов.

Что это значит для пользователей в России

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

Какие еще компании нарушили закон о «приземлении»?

IT-корпораций, которые не стали локализовать свои данные в России, достаточно много. В их числе, например, Twitch, который еще в 2022 году получил претензию от Роскомнадзора.

Тогда компанию оштрафовали на 2 млн рублей, а поисковики обязали помечать платформу как иностранное лицо, нарушающее российское законодательство.

Более серьезные ограничения, с которыми столкнулись AWS и GoDaddy, ранее были наложены на сайты облачного сервиса Kamatera, хостинг-провайдеров WPEngine, HostGator.com, Network Solutions, DreamHost, Bluehost, Ionos и DigitalOcean.

Как все представляли себе работу технологии?

1. Покупатель сканирует QR-код на входе.
2. Камеры и датчики магазина отслеживают, что он берет с собой.
3. Система автоматически формирует чек после того, как клиент вышел.

А как оказалось на самом деле?

Оказывается, в Индии сидело больше ТЫСЯЧИ специально обученных сотрудников. Они просматривали видео с камер и вручную идентифицировали покупки! Никакой тебе крутой нейросети, а обычный ручной труд тысяч людей.

Почему Amazon отказывается от «Just Walk Out»?

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

И чем же Amazon заменит старый подход?

Компания переходит на несколько решений: «умные тележки» и кассы самообслуживания. В тележку для покупок встраивается сканер и экран, а клиент все сканирует прямо во время шоппинга, избегая очередей. Если же у покупателя нет аккаунта Amazon, то он сможет воспользоваться кассой самообслуживания.

Краткое резюме:

1. Саша работает в Amazon в Берлине и делится опытом о том, как устроиться в топовую зарубежную IT-компанию.
2. Работа в Google с детства была его мечтой из-за высоких зарплат, возможности работать по всему миру и дополнительных бонусов, таких как бесплатная еда и места для отдыха.
3. Топовые IT-компании, такие как Google, Twitter, Amazon, имеют схожие условия работы и процесс собеседования.
4. Процесс собеседования включает телефонное интервью и очное собеседование (on-site), для которого кандидатам предоставляются билеты и проживание.
5. Основная часть собеседования – решение алгоритмических задач, которые можно практиковать на сайте Leetcode.
6. Для кандидатов с опытом работы 3-4 года предусмотрен этап System Design, где оценивается способность к проектированию систем.
7. Подготовка к System Design включает изучение различных технологий и подходов к решению задач, рекомендуется сайт Highscalability.
8. На собеседовании могут задавать общие вопросы, связанные с резюме и профессиональным опытом кандидата.
9. Саша утверждает, что устроиться в топовую IT-компанию сложно, но возможно, и предлагает на своем канале полезные материалы для подготовки к собеседованиям.

Ниже — транскрибация ролика от нейросети.

Привет, меня зовут Саша, я работаю в компании Amazon в Берлине, и в этом видео я хочу рассказать вам о том, как попасть в топовую зарубежную IT-компанию. Вообще, лично для меня попасть в Google было мечтой с самого детства, когда я впервые узнал о том, какие там условия работы, что там огромные зарплаты, можно работать в любой стране мира, что там куча еды, пиво в холодильнике, и что главное, поразило меня больше всего, то, что там есть кровати, где можно поспать, если ты вдруг устал после рабочего дня. В общем, все эти бонусы работы в Google достойны отдельного видео. А сейчас давайте перейдем к самому главному. Как пройти собеседование.

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

На самом деле, помимо него есть Twitter, Amazon. В общем, их целая куча. И во всех этих компаниях примерно одинаковые условия работы, одинаковая зарплата. И, что самое главное, у них у всех одинаковый процесс собеседования. Поэтому, как только вы подготавливаетесь к одной компании, вы автоматически подготавливаетесь ко всем.

Телефонное собеседование

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

Очное собеседование

После того, как вы успешно прошли первую часть, то есть телефонное собеседование, вас ждет второе — это очное собеседование или on-site.

Поскольку в России или вообще в странах СНГ мало офисов этих компаний, то вам покупают билеты на самолет, пару ночей в отеле, и вы летите в страну, где есть офис выбранной вами компании.

Это само по себе уже отличное мини-приключение, внутри которого вам нужно пройти 4 или 5 собеседований длительностью по часу. Затем вы летите домой, ждете примерно неделю, и вам говорят результат, да или нет. И вы начинаете торговаться за зарплату, но это уже тема отдельного видеоролика.

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

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

После этого вы будете писать его на абсолютно любом языке программирования, то есть можно на Java, можно на C++, это абсолютно не важно. Здесь главное заранее нарешать как можно больше таких задач, то есть набить руку, потому что в конце концов все эти задачи все равно более-менее похожи. Самым популярным сайтом для решения задач является сайт Litcode. На нем собрано огромное количество задач, которые реально спрашивают людей на собеседованиях. Они разбиты во-первых по темам, а во-вторых по уровню сложности.

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

Этап System Design

System Design — это открытый вопрос уровня спроектирования ленты. То есть у вас есть час времени, за который вы должны поверхностно пробежаться по тому, как вы будете реализовывать это приложение. Главное отличие здесь — это то, что это такой очень открытый вопрос, в котором нет правильного и неправильного ответа. Здесь смотрится скорее на то, как именно вы рассуждаете. Подготовиться к систем-дизайну, с одной стороны, тяжелее, потому что нет такого четкого алгоритма, которому вы должны следовать, чтобы пройти собеседование. Но, с другой стороны, на самом деле, подход к решению всегда одинаковый. То есть, вы всегда будете думать о том, какую базу данных, например, использовать. Там, реляционную или нереляционную. Если не реляционную, то какую именно?

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

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

Заключение

В заключение хочу сказать несколько вещей.

Во-первых, конечно, упасть в топовые IT-компании — это непросто.

Во-вторых, подготовиться и попасть в это вполне реально. Для этого нужно решать просто очень большое количество задач.

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

Соискатели рассказали, как готовились к интервью, какие задачи решали на первых раундах и на какие вопросы отвечали перед HR.

Собеседование в Amazon

Автор этого отчета последовательно готовился к собеседованию в “большую пятерку” FAANG еще с обучения в бакалавриате. Также он писал свой диплом так, чтобы он казался более значимым в глазах собеседующих. На подготовку к собеседованиям у автора ушло 3 года, и его взяли на работу.

Советы

1. Решайте все задачи по теме “Конкурентное программирование”. Также стоит регулярно решать задачки с сайтов как Leetcode, Interviewbit и Codeforces.
2. Регулярно занимайтесь конкурсным программированием.
3. Постоянно обновляйте свое резюме. В нем должны быть хотя бы 2-3 проекта хорошего уровня, чтобы впечатлить интервьюера.
4. Не врите в резюме.

Раунд 1

1. Рассчитать объем воды

Дан массив ‘arr’ типа long размера ‘n’. При этом ‘arr[i]’ обозначает высоту столбца ‘i’.

Рассчитайте объем воды, который можно было бы собрать, если бы из столбцов массива можно было собрать фигуру. Ширина каждого столбца одинакова и равна 1.

Например, ‘n’ = 6, ‘arr’ = [3, 0, 0, 2, 0, 4]. Тогда ответом будет 10.

Нам нужно реализовать функцию, которая высчитывала бы:

1. В первой строке целое число ‘n’, обозначающее размер массива/списка.
2. Во второй строке ‘n’ целых чисел, разделенных пробелами, представляющих высоту столбиков.

Вывод должен содержать целое число, обозначающее количество воды, которое может быть собрано.

2. Реализация LRU-кеша

Разработать и реализовать структуру данных для LRU-кеша для поддержки следующих операций:

1. get(key) – Возвращает значение кэша, если он есть в памяти. В противном случае, функция должна вернуть -1.
2. put(key, value) – Вставить значение в кэш, если ключа еще не существует, или обновить значение ключа, если ключ уже существует. Перед обновлением элемента кэш должен удалить последнее использованное значение.

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

Первая строка ввода должна содержать два разделенных пробелом целых числа ‘C’ и ‘Q’, обозначающих емкость кэш-памяти и количество выполняемых операций соответственно.

Следующие ‘Q’ строк содержат операции, по одной на строку. Каждая операция начинается с целого числа, обозначающего тип операции.

Если число равно 0, то операция относится к первому типу, и за ней следует один целочисленный ключ.

Если число равно 1, то операция относится ко второму типу, и за ней следуют два целых числа key и value (в таком порядке), разделенные пробелами.

Для каждой операции типа 0 выведите целое число в одной строке, которое обозначало бы значение ключа, если ключ существует, или -1.

Значение Q не меньше 1 и не больше 10^4. Значение C не меньше 1 и не больше 10^5. В выводе не может быть значения меньше 1 и больше 10^9. Время выполнения операции не должно превышать секунды.

Раунд 2

На этом раунде присутствовал HR, разговор происходил наедине в Google Meet. Вопросы от HR:

1. Кто является для вас примером для подражания?
2. Что вы ожидаете от этой работы?

Собеседование в IBM

Автор этого отзыва готовился к интервью 4 месяца.

Советы

1. Отработайте не менее 250 вопросов по программированию и разберитесь с концепциями ОС, сетей и баз данных.
2. В резюме должно быть не менее двух хороших проектов.
3. Изучите нюансы конкретной компании перед тем, как прийти на интервью.
4. Не врите в резюме.

Раунд 1

1. Сортировка массива

Вам дан массив ‘arr’, состоящий из ‘n’ элементов. Каждый элемент массива равен 0, 1 или 2. Отсортируйте элементы массива в порядке возрастания. Не создавайте новый массив, просто внесите изменения в существующий.

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

Сперва автор использовал метод сортировки, но интервьюер попросил его не делать этого. Тогда автор просто написал функцию, которая запоминает количество 0, 1 и 2 в массиве.

2. Задача об отрезании веревки

Дана веревка длиной ‘N’ единиц. Она может быть разрезана на части различной длины, и каждый отрезок имеет свою стоимость. Определите максимальное количество вариантов, на которые можно разрезать веревку, вместе с ценами на каждый отрезок.

Размеры отрезков могут варьироваться от 1 до N. При этом сумма отрезков должна равняться N.

Первая строка ввода должна содержать целое число ‘N’, обозначающее длину веревки.

Вторая строка должна содержать вектор ‘A’ размера ‘N’, который показывает стоимость получившихся отрезков, где каждый индекс массива – это поддлина, а элемент с этим индексом – стоимость для этой поддлины.

Поскольку длина отрезка не может равняться 0, то нулевой индекс вектора будет представлять первую поддлину отрезка. Следовательно, индекс N-1 будет представлять стоимость для длины ‘N’.

Раунд 2

Интервьюер спрашивал о проектах, и автор рассказал о них. Затем интервьюер задал несколько вопросов по концепциям ОС.

Вопросы HR:

1. Какие ваши сильные и слабые стороны?
2. Кем вы видите себя через 5 лет?

Собеседование в Microsoft

Автор готовился к собеседованию в течение полугода. В частности, автор решил сделать упор на СУБД и объектно ориентированное программирование.

Советы

1. Практикуйтесь в вопросах по структурам данных и алгоритмам. Можете тренироваться на InterviewBit и выполнять все задания по структурам данных и алгоритмам, которые задают на последних интервью.
2. Решайте задачи на Leetcode. Также стоит участвовать в еженедельных конкурсах, чтобы знать, какие ваши слабые места нужно улучшить.
3. Также стоит изучить основные понятия операционных систем и баз данных.
4. Проведите исследование целей компании и будьте готовы задать некоторые вопросы, связанные с компанией, которые покажут ваш интерес к компании.
5. Ваше резюме должно состоять в основном из навыков, проектов и достижений.
6. Никогда не лгите в своем резюме.

Раунд 1

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

1. Ближайшее число, кратное 10

Вам дано целое число N. Найдите ближайшее к нему число, кратное 10. Если расстояние до чисел равное, выберите меньшее из них. К примеру, если дано число 3, то правильными ответами будут и 30, и 40. В этом случае стоит вывести 30.

2. Вычислить день недели

Напишите функцию, которая вычисляет день недели для любой даты в прошлом или будущем. К примеру, 28 августа 2020 года приходится на пятницу. Следовательно, ответ должен быть “Пятница”.

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

Вывод должен содержать значения из списка {"Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"}.

Также есть ограничения по вводу: число дней не должно превышать 31, число месяцев не должно превышать 12, а год не должен превышать 2,000,000. Кроме того, все эти значения не могут быть меньше 1.

3. Удалить N значений после M значений

У вас есть список и два целых числа «N» и «M». Нужно удалить «N» узлов в списке после количества узлов «M». Иными словами, нужно отсчитать M узлов, после чего удалить N узлов, и так до конца списка.

Первая строка ввода должна содержать элементы односвязного списка, разделенные одним пробелом. Список должен завершаться -1. Следовательно, -1 никогда не будет элементом списка.

Вторая строка должна содержать два целых числа ‘N’ и ‘M’, разделенных одним пробелом.

Вывод должен содержать итоговый список.

Раунд 2

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

1. Найти элемент последовательности

Есть последовательность: 1, 11, 21, 1211, 111221, 312211, 13112221,...

Она строится так. Первое число читается как “один один”, точнее, как “one One”. Значит, и второе число будет “one one”, то есть 11. Число 11 читается как “two One”, то есть третье число будет равно 21. Число 21 читается как “one Two one One”, то есть четвертое число будет равно 1211. И так далее.

Нужно написать код, который позволял бы найти N элемент последовательности. При этом N должно быть не меньше 1 и не больше 40.

2. Составить самое большое число из элементов массива

Вам дан массив ‘ARR’ длины N, состоящий из неотрицательных целых чисел. Используя только эти заданные числа, переставьте их так, чтобы из них составлялось максимально возможное число.

К примеру, задан массив с элементами ’32’, ‘8’, ’29’. Вы должны расположить числа в порядке ‘8’, ’32’, ’29’. Тогда из них можно будет составить максимальное число 83229. Порядок цифр внутри элементов массива изменить нельзя.

Раунд 3

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

1. Упростить путь к файлу

Вам дан путь к файлу/каталогу в стиле Unix длиной N. В файловой системе в стиле Unix точка (.) относится к текущему каталогу. Двойная точка (..) относится к предыдущему каталогу относительно текущего каталога. Если между двумя каталогами имеется несколько косых черт, вы должны превратить их в одну косую черту.

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

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

Ввод должен содержать число Т, которое указывает, сколько каталогов на пути к файлу нужно отобразить. Кроме того, Т не может быть меньше 1 и больше 100.

2. Упростить полином

В странах бывшего СССР полином называют многочленом. Вам дается полином. К примеру, это будет 5x^3 + 2x^3 + 6x^4 + 2. Нужно упростить его.

Количество элементов полинома не должно быть равно нулю и превышать 10, а степени чисел и коэффициенты не должны превышать 10^5.

Раунд 4

На этом этапе интервьюер спрашивал соискателя о его проектах. Вопросы интервьюера:

1. Расскажите обо всех своих проектах.
2. Какая структура у ваших проектов?
3. Как вы проходили летнюю стажировку?
4. Что такое линейная регрессия?

Раунд 5

Этап собеседования с HR. Вопросы:

1. Что такое СУБД?
2. Объясните ACID.
3. Объясните двухуровневую и трехуровневую архитектуру СУБД.
4. Что такое независимость от схемы в СУБД?

Заключение

Надеемся, подборка оказалась полезной. Судя по всему, она предназначена для миддлов: соискатели указывали, что сложности задач была средней, но отнюдь не простой. А получилось ли у вас решить эти задачи?

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

Аналог Copilot X, CodeWhisperer, поддерживает 15 языков программирования. В том числе Python, Java, и JavaScript. А также доступен для кучи IDE, включая VS Code, IntelliJ IDEA, and AWS Cloud9. А ещё он фильтрует предложения кода.

Но самое главное, что он полностью бесплатен. По крайней мере, пока что.

Кроме того, Amazon показала Bedrock — инструмент для создания и масштабирования ИИ-приложений. В нём есть базовые модели от стартапов AI21 Labs, Anthropic и Stability AI.

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

Пока все наблюдали за соревнованием Microsoft, OpenAI и Google, Amazon не теряла времени. А раз конкуренция становится больше, значит, ИИ-инструментов станет ещё больше и они будут доступнее.

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

Особенно меня заинтересовал сертификат AWS Cloud developer, так как я разработчик и мне хотелось более глубоко изучить инструменты. На самом деле, у меня тогда был выбор одного из трех экзаменов более Associate уровня. Для наглядности — карта сертификации AWS.

Курсы для подготовки к сертификации

Я использовал курсы с Udemy:

• AWS Certified Developer Associate Exam Training 2021;
• Можно попробовать и другого преподавателя, например, Ultimate AWS Certified Developer Associate 2021;

Ещё есть официальные курсы, но ими не пользовался.

Они все на английском языке. Скажу сразу, что вариантов сдавать экзамен на русском языке нет.

Для успешной сдачи экзамена нужно набрать 72% процента из 65 вопросов. Длительность экзамена 140 минут, что довольно мало для такого большого числа вопросов. Но я смог получить дополнительные 30 минут.

Сдача теста

Тест можно сдавать из дома, но они предъявляют определённые требования к помещению , где вы будете сдавать экзамен. Я сдавал в специальном компьютерном центре.

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

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

По сравнению с экзаменом AWS Certified Cloud Practitioner вопросы стали объёмнее. Они нацелены на то, как можно решать проблемы. Нередко я видел, что два или три варианта ответа кажутся подходящими, но только один оказывается на 100 процентов правильным. Кроме того, стало намного меньше вопросов на знание того, за что отвечают сервисы.

На какие сервисы нужно обратить особое внимание

На протяжении всего экзамена мне постоянно попадались вопросы на знание CLI команд. Так что для успешной сдачи необходимо знать, как работать с CLI AWS, уметь строить свою private VPC. Большинство вопросов касаются трёх сервисов: Lambda, DynamoDB, ECS (Elastic Container Service). Причём мне потребовалось знать, как все эти три сервиса могут быть интегрированы друг с другом.

В Lambda вам необходимо знать различные типы вызовов функций, асинхронные и синхронные, чем они отличаются, как создавать разные версии функций Lambda, как они отличаются от Aliases, что такое @LambdaEdge, Lambda Environment Variables. Также нужно знать Monitoring, Logging and Tracing.

В части DynamoDB, которая является вторым по важности ресурсом, необходимым для сдачи экзамена, вам необходимо понимать и уметь читать Provisioned Throughput (RCU и WCU). Также нужно знать, чем Scan API отличается от Query API, в чём разница между глобальным вторичным индексом (GSI) и локальным вторичным индексом (LSI), как включить потоки DynamoDB, как добавить время жизни (TTL) для элементов, какая разница между DynamoDB Accelerator (DAX) и Elasticache.

Третья по важности услуга — ECS. В этой области вы должны чётко понимать, что такое Docker, уметь развёртывать свои контейнеры на Fargate и EC2 и, кроме того, понимать разницу между ними. Затем вы сможете развернуть репозиторий контейнеров в ECR. Перед этим вы должны иметь возможность вызывать AutoScaling и Load Balancer для своих контейнеров и понимать стратегии размещения и язык кластерных запросов.

Затем вам нужно знать разницу между сервисами SQS и SNS. Требуется меньше знаний, но они необходимы в IAM, Elastic Beanstalk, RDS, API Gateway, SAM, Route 53, S3 и Cloud Front, балансировке нагрузки и автомасштабировании. А пока вы должны знать сервисы, предоставляемые разработчиком CI / CD: Cloud 9, CodePipeline, CodeCommit, CodeDeploy. Хочу отметить, что этот список не ограничивается только этими услугами.

В Teleperformance больше 380 000 сотрудников. Видеонаблюдение введут для 39 000 из них — столько работает в Колумбии.

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

Видеонаблюдение за удалёнными сотрудниками

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

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

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

Apple против такого подхода

Apple — один из клиентов Teleperformance  — запретила компании использовать мониторинг за сотрудниками. Teleperformance отменила это решение для команд, которые работают с Apple.

Источник: NBC

Почитайте, чем закончился мониторинг эффективности в прошлый раз:

Для этого техногигант нанял группу специалистов по искусственному интеллекту.

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

Такой подход называют гомоморфным шифрованием. Над ним также работают Microsoft, Amazon и Google.

Facebook сообщил, что пока внедрять гомоморфное шифрование в WhatsApp слишком рано. Возможно, понадобится ещё несколько лет.

Источник: The Information

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

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