Как развернуть среду разработки и сервис управления проектами в облаке?
Группа IT-компаний Lad сократила время запуска клиентских проектов, автоматизировала сборку клиентских приложений для iOS и развернула производительную инфраструктуру для публичных сервисов. И все это — на инфраструктуре Selectel.
В основе инфраструктуры — облачные серверы с быстрым запуском, автомасштабированием и возможностью использовать подход GitOps.
Чтобы автоматизировать сборку клиентских приложений для iOS, компания арендовала в Selectel серверы Mac mini®.
За производительность инфраструктуры для публичных сервисов отвечает связка из Managed Kubernetes, Container Registry и S3. Она позволяет поддерживать микросервисную архитектуру с отказоустойчивыми кластерами, автоскейлингом и надежным хранением файлов.
Как группа IT-компаний Lad развернула окружения для разработки и тестирования, а также запустила сервис для управления проектами и ИИ-ассистента для бизнеса, читайте в Академии Selectel.
Вайб-кодинг это TDD в блестящей обёртке и с хорошим пиаром. Change my mind.
И в этом очень-очень много иронии. Давайте прямо: за дцать лет TDD не стал ни стандартом де факто, ни даже общепризнанной хорошей практикой. Если оценим комментарии к местнымстатьямпро TDD, то они скорее всего будут негативными. Даже саму необходимость юнит-тестов постоянно подвергают критике.
Дцать лет апологеты пытаются продвинуть TDD под предлогом улучшения надежности систем и снижения количества дефектов. И дцать лет их полоскают.
Но тут приходит Андрей Карпатый (разработчик ИИ, научно-технический просветитель, ныне больше с креном в инфоцыганство) и говорит страшную вещь. А давайте детально опишем поведение юнита со всеми корнеркейсами и скормим нейронке. А когда нейронка выдаст не совсем то - уточним описание. И так по кругу, пока результат не станет идеальным.
И все такие: ВАУ!!!111 10 ИЗ 10, ГОСПОДИ, 10 ИЗ 10!1
Внезапно оказалось, что если продумать спецификацию, то кодинг - дело техники. А если еще обмазать тестами, то надежность будет железобетонная. И чем детальнее спека, тем лучше результат. Кто бы мог подумать! Хотя погодите-ка...
Мои коллеги по ИТ-компании "Криптонит" пишут на Go. Я попросила их придумать ошибку — сможете её найти? Ждём в комментариях ваши варианты.
package main
import "fmt"
type User struct {
name string
meta map[string]string
}
func (u *User) SetMeta(key, value string) {
u.meta[key] = value
}
func main() {
u := &User{name: "Alice"}
u.SetMeta("role", "admin")
fmt.Println("Meta:", u.meta)
}
.
.
.
ОСТОРОЖНО! ДАЛЬШЕ СПОЙЛЕР
В main() мы создаём указатель на User, но не инициализируем вложенную map[string]string (Meta)
Присвоение значения через u.Meta[key] = value, вызовет панику (panic: assignment to entry in nil map), потому что u.Meta всё ещё nil, и в Go нельзя присваивать значения в nil-мапу.
Одним из вариантов было бы добавить функцию NewUser(), создавать пользователя через нее, и сразу инициализировать мапу:
Второй вариант решения изменить SetMeta что бы инициализировать мапу, если она равна nil
func (u *User) SetMeta(key, value string) {
if u.meta == nil {
u.meta = make(map[string]string)
}
u.meta[key] = value
Ошибку и решение нам помог составить Алексей Косов, системный инженер департамента инфраструктуры в «Криптоните». Его материал про особенности, применение, плюсы и минусы Golang можно прочитать в этой статье.
Вы наконец победили. Потратив большую часть карьеры на охоту за багами, вы достигли невозможного: багов нет. Вообще. Пусто. Доска с багами пуста, QA тихо плачет в углу, а CI-сервер бездельничает, ровно светясь скучно-зелёным цветом. Но вместо того чтобы попасть в рай, вы оказываетесь в лимбе. Если вы играли в игры начала нулевых, это похоже на выход за границы карты: голый ландшафт, странная геометрия и надпись от разработчика: «Ты не должен был оказаться здесь. Но раз уж оказался — молодец, конечно, только смысла в этом нет».
Что происходит дальше? Ничего хорошего. Первый сюрприз — вас никто не похвалит. Бонуса нет, промоушена тоже. Менеджер лениво листает ваш performance-review, хмурится и спрашивает: «А что ты делал весь квартал?» Ты отвечаешь: «Я избавил нас от багов». Он пожимает плечами: «Так они и раньше вроде не были критичными».
Кто-то бросится чинить метрики, и начнётся новый головняк, потому что вы уж слишком постарались. «Багов не может не быть, значит, сломана метрика», — уверены все. Предлагаете метрику «отсутствие багов» — слышите в ответ: «Недоказуемо, выборка мала!»
Вы думали, что победа откроет двери в рай, а распахнули портал в лимб, где невозможно доказать собственную полезность. Пару поколений инженеров мы упорно объясняли бизнесу, что «баги бывают, это нормально». Благодаря нам продакт-оунеры научились бравировать SLA с допуском на косяк. Мы воспели «умеренное количество дефектов» как здоровый холестерин IT-организма — и вдруг вы свели холестерин к нулю.
Парадокс: все процессы настроены на борьбу, а не на мир. Метрике нужен враг, а процессу — вызов. Без них графики плоские, алерты молчат. Добро пожаловать туда, где ваши достижения стоят ровно ничего. Вся организационная религия строилась на борьбе с багами. Уничтожив последний баг, вы «убили бога» процесса. Всё, что давало смысл (defect-метрики, ретро-ритуалы, баг-баунти), обесценивается; наступает инженерный нигилизм. Великая битва окончена, триумфаторов нет, система сломана. Баг умер — и ты его убил!
Совет: в следующий спринт оставьте пару багов — ради здоровья экосистемы.
В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.
Эта трансформация хорошо отражена в более современных источниках:
В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.
В Облаке Рег.ру добавили образ NextCloud + OnlyOffice
Запустили удобное корпоративное хранилище для совместной работы с документами в Облаке Рег.ру. Набор офисных приложений OnlyOffice теперь также доступен в облаке — добавили предустановленный образ NextCloud + OnlyOffice. Обновленное облачное решение предлагает универсальную экосистему для совместной работы:
NextCloud подходит для хранения любых документов и файлов;
OnlyOffice позволяет редактировать документы и закрывает большинство стандартных задач пользователей.
Для заказа доступны облачные серверы во всех локациях. Минимальная конфигурация — 4 vCPU, 16 ГБ RAM, 40 ГБ диска.
Новый образ NextCloud 31 + OnlyOffice 5 уже можно тестировать на нашем сайте.
Если у вас в приоритете — опыт работы над масштабным продуктом и строчка в резюме, с ходу впечатляющая HR-ов… Другими словами, если в ваши карьерные планы входит работа в крупной технологической компании — значит, мы придумали этот тест для вас.
Он поможет сориентироваться: проверить хард- и софтскилы и понять, какие навыки уже на высоком уровне — а что стоит прокачать, чтобы повысить шансы оказаться в бигтехе.
Тест вам подходит, если:
Ваша специальность — разработчик, DevOps-инженер, аналитик данных или ручной тестировщик.
Ваш грейд — джун+ и выше. Нужна теоретическая база, коммерческий опыт или опыт решения учебных проектов на реальных кейсах.
Чтобы давать релевантные задачи, мы консультировались с нанимающими менеджерами Яндекса — они знают, чего ждут от соискателей в больших технологических компаниях.
1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.
Запустили продажу SSL-сертификатов для комплексной защиты сайтов и почтовых сервисов
SSL-сертификаты — цифровые решения, обеспечивающих безопасность передачи конфиденциальных данных пользователей. Они создают защищенное HTTPS-соединение, которое шифрует логины, пароли, банковские реквизиты и личную информацию.
У нас вы сможете приобрести все популярные типы SSL-сертификатов для бизнес-сайтов, личного блога, почтовых сервисов, финансовых организаций и других проектов, работающих с персональными данными пользователей, в частности из России и Беларуси:
🔑 DV — быстрая проверка домена.
🔑 OV/EV — расширенная проверка организации.
🔑 Wildcard — защита неограниченного количества поддоменов.
🔑 SAN — решение для мультидоменных проектов и почтовых сервисов.
Повышайте доверие своих пользователей и улучшайте поисковую оптимизацию!
Это заключительный эпизод курса «Паттерны и практики написания кода». В нём бэкенд-инженер Юра Афанасьев расскажет про истоки возникновения паттернов, а также объяснит, как урбанизм и проектирование городов помогли в создании книги «Паттерны проектирования». Напоследок Юра также разберёт два фундаментальных правила, описанных в книге «Design Patterns».
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Как сделать неудачнуюплатформу для разработчиков?Обсудили в новом выпуске подкаста про 10 грехов DevEx 🔥
В этот раз наш гость Артём Арюткин, руководитель проекта офиса Яндекс, рассказал Cloud.ru про главные ловушки платформенной разработки, что не является DevEx, а также, какой должна быть идеальная платформа.
А еще в выпуске:
почему стандартные метрики вредны для реального положения дел в команде;
как когнитивная нагрузка убивает продуктивность (и при этом импортозамещение);
чем опасна «гибкость» инструментов и когда стандартизация спасает проекты;
почему онбординг новых разработчиков — лучший стресс-тест для платформы.
Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'. Но почему-то через полгода таких разговоров оказывается, что:
баг, который 'уже почти пофиксили' никуда из прода не девался фича, которую 'вот-вот запустим' — всё ещё в черновиках команда уже тихо ненавидит слово 'архитектура'
А техлид? Техлид как будто ничего не замечает. Как это работает (точнее, не работает) Слова вместо кода
вместо пулл-реквестов - диаграммы. демо нет - зато вот вам слайды. вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').
Бесконечный 'анализ'
'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться' 'Это нетривиальная задача' = 'Мне лень разбираться'
Ответственность - это не про нас Любимый приём - щедро размазать вину:
'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').
Реальный кейс (чтобы было не абстрактно)
В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу. Провёл 8 митингов, написал 50 страниц документации.
А потом... уволился.
Оставив после себя: красивые схемы в Confluence ни одной строчки кода команду, которая теперь на рефакторинг смотреть не может
Как понять, что ваш техлид центральная часть системы самообмана?
главный результат его работы - не код, а презентации коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует) после разговора с ним хочется или закодить, или закопать
Что прикажете с этим делать?
тупо запретить 'стратегировать' без кода* нет пулл-реквеста - нет права говорить про архитектуру.
ввести 'день испанского стыда' раз в месяц техлид показывает руками, что сделал. Не слайды - код.
Задавать всего один вопрос
'Что конкретно изменится после твоего решения?' Если ответ начинается со слов 'теоретически....' - это тревога.
Вывод Хороший техлид — не тот, кто красиво говорит о проблемах. А тот, кто их решает.
Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.
P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение
Запускаем трёхнедельный СI/CD практикум — будем учиться решать реальные задачи и применять best practices CI/CD.
Через 3 недели курса вы научитесь:
Разбираться в структуре пайплайна и GitLab CI
Читать документацию, находить и адаптировать решения под задачу
Обосновывать и отстаивать технические решения
Проводить технический траблшутинг
Определять, как автоматизировать повторяющиеся задачи и не делать руками то, что может сделать пайплайн
Автор практикума — Вячеслав Федосеев, TeamLead DevOps в «Честном знаке» и ментор курса DevOps Upgrade.
Курс для вас, если вы: уже работаете в IT от 1 года, знакомы с GitLab и GitLab CI (на базовом уровне) , хотите уверенно строить пайплайны и решать нестандартные кейсы
Если вы чувствуете, что теории недостаточно — необходимы опыт и фидбэк, присоединяйтесь к обучению — старт 21 июля.
Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов
Воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.
Что будет на воркшопе:
Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор инструментов:
Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала;
PSP/PSS Baseline — стандарты безопасности Kubernetes.
Практика:
Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
Создание и отладка IaC (Kubernetes YAML, Terraform) с помощью AI-ассистентов: выявление и исправление ошибок;
Генерация понятной и структурированной документации к проектам с помощью AI;
Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.
А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.
Когда: 5 июля 2025 года
Узнать подробности и занять место на воркшопе — через бота.
Последние из группы Поведенческих паттернов: Хранитель и Шаблонный метод
В одиннадцатой серии курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Юрой Афанасьевым завершаем тему Поведенческих паттернов. Последние два подхода, которые разберем в эпизоде: Хранитель и Шаблонный метод. Подробнее про их реализацию в коде, преимущества и недостатки — в эпизоде.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Развернуть высоконагруженную платформу в Managed Kubernetes, ориентированную и на b2b-, и на b2c-сегменты — задачка со звездочкой. Как это сделать, рассказываем в Академии Selectel на примере кейса компании TrendTech.
Вы узнаете, как компания:
обеспечила отказоустойчивость сервисов, сохранив возможность гибкого масштабирования;
автоматизировала обновление контента из более чем 5 000 источников данных;
обеспечила отдачу и надежное хранение тяжелых файлов;
развернула удобное окружение для команды разработки.
Перенимайте опыт TrendTech и используйте Managed Kubernetes для реализации своих проектов.
