Технотекст

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

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

Серьезные инциденты случаются со всеми, даже с глобальными игроками. Чего стоил один только прошлогодний сбой у Toyota! Тогда переполнение дискового пространства и сбой в СУБД стали причиной остановки всех заводов компании в Японии. А недавно произошла хакерская атака на СДЭК. В таких ситуациях остается надеяться только на бэкапы.

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

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

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

Когда поднимаешь сеть на только что отстроенном объекте, в идеальном мире строители уже подготовили для тебя помещения, протянули СКС, подвели питание и сделали всё что нужно. В реальности синхронизации между поднимающими сеть интеграторами и строителями не всегда придают должное значение. Что может пойти не так?

Расскажу вам об очень показательном кейсе такого рассинхрона. Я Сергей Шульгин, эксперт по сетевым технологиям ИТ-компании К2Тех. И этой историей я как бы намекаю, зачем в крупных проектах нужен технадзор и почему мудрые заказчики кровью вписывают его в договор с интеграторами.

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

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

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

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

Привет, Хабр! Меня зовут Георгий Меликов, я из VK Cloud и руковожу там инфраструктурной разработкой (IaaS) облака, где мы создаём SDN (Software Defined Networks) — программно определяемые сети; SDS (Software Defined Storages) — программно определяемые хранилища; и другие решения.

А ещё на досуге я — контрибьютор файловой системы OpenZFS с 2016 года.

В этой статье поговорим о наших подходах к разработке на примере создания нашего SDN. Мы ставим перед собой несколько целей:

1) Разрабатывать быстро, чтобы итерации были явно очерченными  и понятными. Хотим, чтобы у нас вырабатывался дофамин от закрытия спринтов, и было понятно, как жить дальше.

2) Эксплуатировать системы без людей — полностью автоматически.

3) Использовать принцип «Дизайн на отказ». Система должна уметь переживать любой возможный сбой и проблему, т.е.обладать так называемым качеством самовосстановления (self-healing).

Предлагаю пройтись эволюционно от простого примера "облака на минималках" до нашей production среды на несколько ЦОДов, собрав по пути проблемы из нашей реальной жизни.

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

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

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

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

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

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

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

Всем привет! На связи руководители Frontend‑практики ГК Юзтех. В этой статье мы подводим итоги 2024 года и делимся нашими прогнозами на 2025 год. Приводим мнение трех экспертов по ключевым трендам фронтенд‑разработки и фреймворков, которые будут актуальными в следующем году.

Елизавета Акманова, старший аналитик ГК Юзтех, снова на связи. Сегодня у меня в планах обсудить, зачем и где нужны API Gateway. Для этого верхнеуровнево пройдём по архитектуре этого паттерна, рассмотрим решаемые задачи. Ключевой вопрос на сегодня: Когда стоит использовать эту технологию? Это полезный инструмент но, увы, не всегда.

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

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

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

Меня зовут Станислав Погоржельский, я технологический евангелист VK Cloud, и в том числе в рамках своей работы рассказываю про наши облачные и on-prem решения. В этой статье мне захотелось поделиться, как именно объектное хранилище S3 помогает решать реальные задачи.

Как я стал core-разработчиком CPython в 19 лет: История усилий и достижений

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

Привет, Хабр! Меня зовут Дмитрий, я работаю в YADRO. Я прошел большой путь в самостоятельном изучении языков программирования: от SQL до Go. Сначала я вообще не документировал процесс обучения, затем стал вести заметки по «академическому» принципу — писал конспекты, как в университете. Пока не открыл древовидную систему хранения данных, которая лежит в основе метода Цеттелькастен. 

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

Всем привет! Меня зовут Никита, я работаю в центре машинного обучения «Инфосистемы Джет». Сейчас я учусь в своей второй магистратуре в ВШЭ ФКН на программе «Современные компьютерные науки» и в Школе анализа данных (ШАД). Сегодня я хочу рассказать о сравнительно новой концепции, которая становится все более актуальной и использование которой совершенно точно необходимо в больших промышленных ML-проектах, — MLSecOps.

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

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

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

Почти — потому что используется всего две функции из библиотеки:

Создать элемент DOM

Обновить элемент DOM

Эта библиотека упрощает использование нативных функций DOM, таких как createElement и replaceChild. Библиотека Fusor направлена на то, чтобы сделать эти функции проще и компактнее.

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