Облачные сервисы *

Думаю, не будет большой ошибкой предположить, что ваш смартфон имеет накопитель минимум на 128 ГБ, больше половины из которых почти наверняка занимают фотографии, какие-то случайные видео и, конечно, скриншоты. Держать это все во встроенной памяти, конечно, можно. Но тогда есть риск, что оставшегося пространства банально не хватит для новых приложений и Телеграма с Ватсапом, которые имеют свойство разрастаться очень и очень сильно. Значит, все это добро надо куда-то деть. Вопрос в том – куда. Облако – ненадежно. Свое железо – надежно, но дорого. Или наоборот… В общем, давайте посмотрим на вещи объективно и постараемся понять, где лучше всего хранить свои данные.

Когда несколько лет назад (в 21 году) я собирал новый домашний сервер вместо Microserver Gen8, я считал, что он мне прослужит лет десять. Но в этом году концепция поменялась, потому затеял замену.

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

Привет, Хабр! С вами Александр Константинов, технический эксперт по облачным технологиям из Cloud.ru. Сегодня хочу показать вам наглядно, как можно оптимизировать производительность веб-приложения. Рассмотрим это на усредненном примере кейса, который типичен для многих наших клиентов, пройдем весь путь настройки, выполним нагрузочное тестирование и сравним до/после.

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

Привет, Хабр! Меня зовут Антон Ивахненко, я технический директор группы Рунити и по совместительству — СТО в РБК.

Когда-то я сам впервые оказался в роли СТО. Тогда Рунити еще не существовало, и разработка в компании была относительно небольшой. А потом — слияния, рост, новые структуры, десятки направлений. Со временем мне довелось искать и адаптировать руководителей разработки, выстраивать команды с нуля и смотреть, как люди по-разному проживают одну и ту же роль. Кто-то брался тащить всё на себе, кто-то терял темп на втором месяце, кто-то выстраивал всё удивительно спокойно — и всё работало.

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

Современные языковые модели (LLM) вроде GPT, LLaMA или Mistral обладают поразительной универсальностью. Они обучены на триллионах токенов из открытых источников и научились объяснять сложные вещи, поддерживать диалог в свободной форме и даже писать код. Однако при решении реальных бизнес-задач универсальность становится слабым местом: бизнесу нужны не «всезнающие ассистенты», а узкоспециализированные инструменты, хорошо понимающие внутренние процессы и терминологию.

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

Меня зовут Юлия Рубцова, я ведущий менеджер продукта Yandex Monitoring. В этой серии статей я и мой коллега Владимир Гордийчук @gordiychuk рассказываем про реальные сценарии использования мониторинга облачных решений. Что вас ждёт: мы покажем, как настроить дашборды, быстро проверить гипотезы при расследовании инцидента, а в конце соберём лучшие практики для настройки мониторинга. 

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

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

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

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

В Ситидрайве Kubernetes обновляют регулярно — инфраструктура большая, и актуальность версий критически важна. После апгрейда до версии 1.29.15 один из GPU-узлов внезапно «забыл» о своей видеокарте, и нам пришлось срочно искать решение. В этой статье я расскажу, в чём была причина бага и как Time-Slicing помог повысить утилизацию GPU. Статья будет полезна всем, кто работает с GPU в Kubernetes и хочет избежать подобных сюрпризов в продакшене.

Хранение файлов в S3 выглядит просто: добавляете объект в бакет по ключу и потом при необходимости удаляете или обновляете его. Но в реальной работе можно загрузить файл с помощью операции PutObject, не проверив, что в бакете уже лежит файл с этим ключом. В результате новое содержимое незаметно заменит старое. Или можно случайно удалить только что добавленный свежий бэкап вместо старого, что нарушает рабочий процесс. Чтобы избежать подобных ситуаций, в S3 есть условные операции записи (conditional write) — это когда действия вроде PutObject, CopyObject, DeleteObject или CompleteMultipartUpload выполняются только при соблюдении заданных условий.

Всем привет! Меня зовут Клюев Алексей, я старший разработчик S3-совместимого объектного хранилища в Selectel. В этой статье мы разберем, как работают условные заголовки, зачем они нужны и как применять их на практике. В качестве примеров будем использовать язык Go и aws-sdk-go v2.

В нашей практике DevOps мы столкнулись с задачей оптимизации Kubernetes-кластера в AWS, включая перевод нагрузки на ARM64-инстансы с процессорами Graviton и эффективное использование spot-инстансов. Благодаря Amazon EKS и Karpenter нам удалось ускорить ввод новых узлов до всего 40 секунд и успевать переносить нагрузку при отборе узлов со стороны AWS. При этом мы сохранили привычный набор инструментов Deckhouse для мониторинга и управления — статья подробно рассказывает о нашем опыте и решениях.

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

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

Привет, Хабр! На связи снова Максим Михайлов и моя серия статей про внедрение AI в клиентскую поддержку Cloud.ru.

В прошлой статье я рассказывал, как мы начали осваивать AI в бою — генеративные подсказки, которые помогают инженерам поддержки готовить ответы, и инструмент, который делает эти ответы дружелюбнее. Но это был только разогрев. Сегодня покажу нашу систему AI-агентов, которые дружно работают внутри технической поддержки Cloud.ru и самостоятельно обрабатывают больше 20% обращений.

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

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

Подробный разбор сборки и настройки домашнего NAS: выбор SAS-дисков и контроллера, настройка ZFS-пула, установка TrueNAS SCALE, организация резервного копирования в S3 и запуск Docker-сервисов (Immich, Affine, Keycloak, Actual Budget). Небольшой гайд для тех, кто хочет построить своё хранилище и цифровую инфраструктуру под полным контролем.

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

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

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

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

Перед тем, как платить за доступ к моделям (особенно дорогим), полезно «пощупать» их на своих задачах. В этой статье я продемонстрировала рабочий способ бесплатно сравнить топовые модели ИИ на примере платной Seedream v4 (ByteDance) и Nano Banana (Google) через сайт Yupp.ai. Эта платформа показывает два ответа разных моделей, вы выбираете лучший, оставляете короткий фидбек и зарабатываете кредиты, которыми «оплачиваете» последующие прогоны. Затем вы уже сами выбираете, какие именно модели (даже платные) хотите тестировать