Amazon Web Services *

Прывітаначкі, похоже с одной стороны сегодня программистов нужно меньше чем раньше, с другой стороны - благодаря LLM действительно можно делать задачи на порядок быстрее. Предполагаю, что в ручную этого бота я бы делал месяц, через Codex gpt-5.5 xhigh - часа три.

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

Про другие неофициальные клиенты:

Я мантейнер Geeknote - неофициальный CLI на Питоне, он внутри моего бота.

NixNote на C++

CliNote на Go - недавно заархивирован - feel free to форкнуть и починить.

И вот теперь я сделал Телеграм бота https://gitlab.com/vitaly-zdanevich/bot_telegram_evernote

На Питоне - хотя я предпочитаю Go - но Geeknote зависимость на нём, так что для единообразия.

Этот бот selfhosted - то есть у каждого он свой. Выбрал такое решение из-за безопасности - вам не нужно доверять моему серверу - запускаете Terraform команду - и бекенд из одной лямды разворачивается у вас. AWS Lambda - для такого сервиса это значит бесплатный бекенд - на 3 GB ARM инстансе это около 4000 бесплатных вызовов в месяц, если среднее время работы будет составлять очень медленные 10 секунд (обычно отвечает за несколько секунд).

Хабровчане, приветствую! Меня зовут Михаил Казанцев, я ведущий системный аналитик в мобильном приложении Вайлдберриз. Работал и писал требования как в стартапах с монолитами, так и в банковском секторе с сотнями сервисов в одном контуре, рассказать есть что.

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

Удары Ирана по дата-центрам в Персидском заливе поставили под вопрос безопасность ИТ-инфраструктуры.

Хочу рассказать о конфигурации AI-агента для полного цикла разработки (SDLC), которую я обкатал на паре своих pet-проектов. Суть: цепочка из пяти команд — от черновика фичи до готового к ревью кода — где каждый этап выполняет AI, а я контролирую и корректирую результат между этапами.

За вечер (3-4 часа) в таком режиме AI выкатывает фичу, ручная разработка которой “по вечерам” занимала бы неделю (15-20 часов). Никаких откровений тут нет — всё, что описывается, обсуждалось тысячи раз. Новизна в том, что из общеизвестных кубиков получилось собрать работающий конвейер, которым удобно пользоваться каждый день.

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

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

Масштабы

• 400+ триллионов⁴ объектов

• 150 миллионов запросов в секунду

• > 1 ПБ/с пикового трафика

• Десятки миллионов дисков

А что лежит в основе всего этого?

Жёсткие диски.

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

Жёсткие диски (HDD) — это старая, уже выходящая из моды технология, во многом вытесненная SSDs. Жёсткие диски хрупки физически, ограничены по IOPS и имеют высокие задержки.

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

Привет, Habr!

Меня зовут Максим Юрченко, я руководитель группы DevOps-инженеров в Lenta tech («Группа Лента»). В статье я расскажу о том, как за последние четыре года менялась наша система логирования, какие решения мы принимали по ходу роста инфраструктуры и к какому результату в итоге пришли (спойлер — без подводных камней и граблей не обошлось).

Здравствуйте, товарищи! Недавно мне понадобилось сделать простой бэкенд для онлайн-песочницы в своем open source проекте. Сейчас для таких задач есть много конструкторов и low-code решений, типа n8n. Но я "по старинке" решил взять serverless с лямбдами, поскольку в позапрошлой компании плотно работал с этим стеком.

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

Мы избавились от «вечно живущих» EC2‑инстансов, настроили масштабируемые GitLab Runner’ы через Fleeting и Autoscaler и при этом сократили расходы на CI‑инфраструктуру. Делимся рабочими конфигами, подводными камнями и практическим гайдом по настройке.

В нашей компании AnyMaint, которая занимается разработкой софта для управления техническим обслуживанием и ремонтом (CMMS) промышленного оборудования, одной из главных задач является нормализация имён тулов (инструментов). Под «тулом» мы подразумеваем любой промышленный актив: машины, станки, приборы, оборудование и т.д.

Статья основана на реальном опыте разработки и эксплуатации системы в течение 28 месяцев: от MVP до попытки миграции.

Ни один сервис не был вымышленным. Ни одна цифра — не придумана.

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

19–20 октября 2025 года в регионе us-east-1 произошёл каскадный сбой, повлиявший на доступность глобальных сервисов. Компания AWS опубликовала детальный разбор, в котором раскрыла первопричину — дефект в автоматизированной системе управления DNS для сервиса DynamoDB. В статье приводятся полная хронология событий, описание воздействия на смежные сервисы (EC2, NLB, Lambda) и список запланированных улучшений для предотвращения подобных инцидентов в будущем.

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

Мрачным утром 20 октября 2025 года мониторинг AWS был краснее некуда, его залило кровью сервисов. Пал крупнейший и по совместительству старейший регион, обрабатывающий 35–40% всего глобального трафика AWS — US-EAST-1. На его воскрешение чернокнижники из AWS потратили 13 часов.

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

Terraform Actions — это новая концепция, представленная в Terraform 1.14, которая позволяет выполнять операции вне стандартного рабочего процесса CRUD (Create-Read-Update-Delete). Это расширяет возможности Terraform, позволяя взаимодействовать с ресурсами способами, для которых раньше требовались другие инструменты, например Ansible.

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

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

Всем привет! Меня зовут Роман, и я хочу поделиться своим опытом сдачи экзамена AWS DEA-C01: Data Engineer Associate. Когда сам готовился, то много искал реальных отзывов и заметок о том, как проходит экзамен, как лучше всего готовиться и на что обращать внимание. Поэтому надеюсь, что мой опыт будет полезен.

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

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

Так у меня и появилась первая цель — подготовиться и успешно сдать экзамен DEA-C01.

От Kubernetes-хаоса к Infrastructure 2.0: опыт EXANTE, ошибки, неожиданные инсайты и новые подходы к современной инфраструктуре будущего

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

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

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

На 23 июля 2025 года AWS удалил мой аккаунт, которому было 10 лет, и каждый байт данных, который я там хранил. Без предупреждения. Без льготного периода. Без возможности восстановления. Произошла полная цифровая аннигиляция.

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.