Привет всем!

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

Я люблю и одновременно ненавижу статьи-обзоры в стиле «10 программ для {whatever}». Ненавижу — потому что их очень легко делать, вбил в гугл «программа для X», взял первые 10 ссылок, статья готова. Я называю такие статьи «лёгкий рейтинг». А люблю я их за то, что даже если 9 пунктов — чушь полная, то десятый, как правило, годный, я узнаю что-то новое, это что-то облегчает мне жизнь и позволяет мне быть более продуктивным.

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

Статья получилась ОГРОМНАЯ, и у меня был большой соблазн разбить её на сотню статей поменьше, чтобы в каждой ставить ссылки на свой телеграм-канал и получать гонорар за каждую по отдельности. Но я не буду. Пусть знания будут сгруппированы вместе. Welcome!

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

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

Выбрали хороший ресторан (врача, СТО, юриста, риэлтора) по отзывам и высокому рейтингу в 2GIS, а оказалось, что там если не ужас-ужас-ужас, то как-то средне, явно не похоже на то, что вы бы ожидали от рейтинга 4.8 или даже 5 баллов. Знакомо?

Все знают, что в 2GIS могут быть накрученные фейковые отзывы (а их там всего 10-20 на весь город или там 99% фейковых? Есть ведь разница!), но не все умеют их легко опознавать. У 2gis, похоже, еще нет антифрода (что вполне нормально для пет-проекта, который делают веб-программисты в свободное время), но вы теперь можете различать ботов-зомби-инопланетян через мой антифрод af2gis, и выбирать себе те заведения, которые нравятся людям, а не ботам.

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

Под Новый Год мы с женой пересматриваем одну популярную магическую сагу — хочется знаете ли в жизни волшебства. В IT волшебства тоже хватает — от танцев с бубнами до самых современных технологий, принцип работы которых проще объяснить тёмной магией. Так, например, бытует мнение, что настройка service mesh — это магия, подвластная лишь волшебникам DevOps. Но у нас в Альфа-Банке разработчики исторически не маглы, а, как минимум, полукровки, поэтому имеют право приобщиться к волшебному миру.

В этой серии статей я хочу поделиться опытом изучения технологии service mesh, а именно Istio, на примере практической задачи, возникшей какое то время назад в одной из систем Альфа Банка, системным архитектором которой я являюсь.

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

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

Предлагаю сегодня поговорить про синдром самозванца среди специалистов, находящихся в зоне риска в связи со стремительным развитием IT‑сферы, — QA‑инженеров, тестировщиков и специалистов области обеспечения качества.

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

Это мой второй доклад про Istio и Service Mesh. Первый я сделал на конференции Kuber Conf 2021: «Что ждать от внедрения Istio?». Рекомендую ознакомиться сначала с ним, будет несколько проще.

Istio — частный случай «сервисной сетки» (Service Mesh), понятия, о котором наверняка все слышали, и многие даже знают, что это такое. Мой доклад на Kuber Conf 2021 (мероприятие Yandex.Cloud, которое проходило 24 июня в Москве) посвящен возможным проблемам, к которым надо готовиться при внедрении Istio. Среди прочего я рассказал о том, как Istio влияет на трафик, какие есть возможности для его мониторинга, насколько безопасен mTLS.

Доклад отчасти отражает наш опыт работы с Istio как с одним из компонентов Kubernetes-платформы Deckhouse, отчасти основан на результатах внутренних нагрузочных тестов.

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

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

Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему — технический долг и как с ним работать.

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

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

Почему при всей продуктивности AI-ассистентов качество кода не растёт пропорционально?
AI-инструменты великолепно справляются с начальными 70% работы, но завершающие 30% по-прежнему требуют инженерной экспертизы. Парадоксально, но эти инструменты приносят больше пользы опытным разработчикам, а не новичкам. Исследования показывают, что около 75% разработчиков уже используют AI в своей работе.

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

Поговорим не о разработке, а о том, как я путешествовал на парусной яхте. Если коротко: летом 2024-го я впервые получил Шенген, купил яхту и пошёл на ней в Африку через всю Европу, застав Олимпиаду в Париже.

Под катом подробная история, как в 45 лет я стал капитаном собственной яхты, хотя я разработчик, а не олигарх. Где можно получить лодку бесплатно, а где не стоит брать и за деньги? Под каким флагом идти по Европе в наше штормовое время? Какие гаджеты и симка точно нужны для плавания? Всё это под катом.

Привет! Это Александр, DevOps инженер из Банки.ру. В прошлой статье я рассказал про сборку сетевого хранилища на базе XPenology. Сегодня продолжу тему Proxmox и XPenology и поделюсь историей о неудачном апгрейде инженерными CPU мини-ПК Lenovo из первой статьи и чем она закончилась.

Всем привет! Меня зовут Женя. Я инженер поддержки бизнес-приложений в компании Банки.ру.
Не так давно мы в направлении Мобайл решили прокачать технический и продуктовый мониторинг и с этой целью начали использовать Zabbix. В результате всю логику алертинга перенесли из Grafana в новый инструмент. Благодаря этому и родилась идея поделиться опробованными фишками Zabbix с сообществом. 

В этой статье я:

• расскажу об интересных возможностях Zabbix;
• поделюсь кейсами их использования и примерами настроек;
• сравню Zabbix и Grafana и расскажу, как мы применяем их в тандеме.

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

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Привет, Хабр! Я Алексей Рыбак, предприниматель и основатель R&D-лаборатории DevHands, автор телеграм-канала про System Design и Highload. В прошлом — СТО и руководитель московского офиса Badoo. Работал во втором по размеру такси-сервисе «Везёт», который мы после продажи интегрировали с Яндекс.Такси. Сейчас наша компания разрабатывает образовательные программы по Highload и перформансу.

Всем привет! Я Борис Зырянов, разработчик в команде Платформы. В этой статье хочу рассказать про Dependency Inversion Principle, потому что это, пожалуй, один из самых важных принципов SOLID, понимание которого дает ключи к архитектуре программного обеспечения. 

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

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

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

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

Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-подразделении Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

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

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

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.

Плюс, регресс — штука дорогая, ведь в это время команда (особенно QA) не занимается созданием новой ценности для заказчика и пользователя, а перелопачивает старую.

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