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

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

Добрый день, меня зовут Андрей, я специалист по администрированию баз данных в компании «Сервионика». За 2,5 года под моим контролем побывало около 700 кластеров баз данных, из которых 80 % — High Avaiability, треть из них — это трёхнодовые полноценные кластеры, где есть мастер, синхронная и асинхронная реплики. Также были успешно проведены проекты по миграции с Oracle и MSSQL на PostgreSQL.

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

Привет, Хабр! Меня зовут Александр Митин, я работаю в Т1 на проектах одного крупного банка. Занимаюсь развитием продкутовых сервисов компании (проект по обслуживанию и проведению ЧДП/ПДП клиентов). Опыт разработки 13 лет, последние 5 лет — в финтехе.

Сегодня микросервисная архитектура используется во многих проектах. Зачастую в таких системах применяют журналирование, авторизацию и прочие служебные сервисы, общие для всех приложений. А при разработке возникает огромное желание не дублировать одну и ту же логику, а вынести её в отдельную библиотеку, тем самым переиспользовав код. Что мы имеем в итоге? В лучшем случае одну библиотеку «common», которая разрастается до огромных размеров и становится ядром распределённого монолита. В дальнейшем новые версии этой библиотеки теряют обратную совместимость, а каждое её обновление в проектах сильно осложняет поддержку. Более того, становится невозможным разобраться, где и какие классы используются, что делает архитектуру хрупкой и уязвимой.

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

Меня зовут Ксения Бирюкова, я владелец продукта Платформы Сфера, разработанной холдингом Т1. В одном из моих проектов мы с командой пытались проводить нагрузочное тестирование. Тогда это казалось очень сложным: пробовали тестировать каждый модуль отдельно, связь с legacy-монолитом не помогала, возникали проблемы с написанием генератора псевдо-уникальных персональных данных и многое другое. И хотя результат был достигнут, ресурсов мы потратили гораздо больше, чем планировали. В итоге собрали список ошибок и задумались, как сделать нагрузочное тестирование менее болезненным. Разберём на своих и чужих примерах.

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

Мы сосредоточимся на двух ключевых элементах безопасности в Kubernetes: Role-Based Access Control (RBAC) и Pod Security Admission. Эти механизмы играют важную роль не только в обеспечении безопасности приложений и данных в кластере, но и в управлении доступом и сетевыми взаимодействиями.

Элементы безопасности, такие как RBAC и Pod Security Admission, играют ключевую роль в обеспечении стабильности и эффективности работы приложений в Kubernetes, особенно при обработке больших объёмов данных и высокой нагрузке. Например, в ситуации с масштабируемым веб-приложением, которое управляет значительными объёмами пользовательских данных и транзакций, настройка этих механизмов может существенно улучшить управление доступом и сетевую безопасность. Это, в свою очередь, помогает предотвратить потенциальные угрозы и атаки, что критически важно для поддержания производительности и доступности данных. Таким образом, эффективно настроенные компоненты безопасности обеспечивают надёжный доступ к данным и минимизируют риски, связанные с увеличением нагрузки на приложение, улучшая общий пользовательский опыт.

Теперь давайте рассмотрим каждый из этих элементов более подробно.

Привет, Хабр! Меня зовут Марат Цконян, я из солнечной Испании, университет Аликанте. Компьютерный инженер по образованию, по опыту работы — системный администратор.

В прошлом году я наткнулся на исследование отечественного DevOps-рынка за 2022 год: там Холдинг Т1 проводил аналитику трендов, а также формализовал проблематику индустрии. Теперь же благодаря Хабру мне предоставилась возможность обсудить накопившиеся вопросы непосредственно с авторами этой работы. 

Я поговорил с Евгением Калашниковым, соавтором исследования и директором по продуктам инженерных инструментов платформы «Сфера». Мы обсудили исследование, поняли, что такое DevOps и кто такие девопсеры, порассуждали, существуют ли DevSecOps и зачем компаниям облака. Заодно заглянули в будущее, узнав, что нас ждёт в исследовании за 2023 год.

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

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

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

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

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

Например, часто в компаниях недооценивают сложность трансформационных процессов: «пересадить» людей на новый программный продукт вовсе не так просто, даже если его функции аналогичны привычному ПО. 

• PersistentVolumes (PV).
• PersistentVolumeClaims (PVC).
• Storage Classes.

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

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

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

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

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

Проектный менеджмент в больших компаниях: почему необходим единый подход?

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

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

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