Добрый день!

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

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

В Jira я увидел название задачи. И она называется "Интеграция c логистической компанией_Костыль",
А в связях у нее есть прекрасная задача,созданная на 6 месяцев позже, с названием "***_Костыль2".
Т.е. " все всё понимали" . И в моменте понимали, и через пол года... Но вот сменилась команда и встала задача поменять фтп на esb .

И как вы думаете, возникла ли хоть одна идея взять и переписать этот костыль на нормальное решение? Правильно! Конечно же нет. Опять нет времени, опять нет возможности.

Нельзя копить технический долг. Вариант "мы сейчас сделаем так, а потом исправим" не работает в 99.9% случаев!

Что же делать⁉️
- Внедряйте средства статического анализа и пороги качества кода, чтобы уменьшить количество мусора у вас в базе;

- Внедряйте Ревью кода, и вычищайте спорные реализации на этапе разработки задач;

- Убеждайте менеджмент в том, что сэкономленные 8 ч\ч сейчас отзовутся такой инфляцией трудозатрат позже, что и представить страшно.

На курсе, мы подробно разберем способы работы с техническим долгом.

Всем привет, мне нужна ваша помощь!

Если вам интересна эта тема DevOps, но вы еще не погружались в нее и вам было бы интересно с чего-то, напишите мне пожалуйста @Segate.
Мне нужно задать вам несколько вопросов, а взамен на ваше время, я попытаюсь ответить на ваши вопросы про то, с чего начинать, куда смотреть и тд, и тп.

Добрый день.

Звезды сошлись, чтобы это стало возможным!

‼️Я объявляю набор на онлайн-интенсив "🥇Zero to hero" ‼️

· Вы опять наткнулись на чужой костыль в коде и не можете понять зачем он тут?
· Ошибок в проде с каждым релизом все больше?
· Или может вы опять обновляли рабочий контур в 5 утра?

Вы хотите это поменять, но никак не соберетесь начать разбираться в теме? Тогда вам ко мне!

🕝Старт уже 6го февраля

· Это мини-группа в 5 человек, чьи проблемы мы будем решать вместе.
· Чат со мной для решения Ваших проблем на Вашем проекте.
· Это месяц личной работы со мной над ВАШИМИ проблемами.
· Индивидуальный план для каждого из студентов!
· Гарантированный результат! За месяц интенсива вы добьетесь реальных результатов в автоматизации конкретно Вашего проекта.

Ну и 🍒 на торте.
Моим коллегам нужен 1с DevOps-инженер. По результатам курса всем студентам будет предоставлена возможность пройти собеседование с моей рекомендацией. Лучший из вас получит возможность работать в крупной компании.

Цена интенсива 30000 рублей.

➡️Оcтавляйте заявки⬅️

Добрый день.

Захотелось сегодня написать про проблемы которые будут на регулярной основе преследовать вас в ежедневной работе.

Вы знали, что по статистике 70% неудач при попытке внедрить что-то новое, не достигают результата из-за сопротивления сотрудников⁉️ В лучшем случае они просто не слишком заинтересованы, а в худшем — активно сопротивляются новому.

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

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

Теория управления изменениями гласит, что нужно устраивать обучение, объяснять ценность, собирать обратную связь и все будет прекрасно... Звучит конечно круто, но не работает.
На деле - на обучении все скучают, потом просто максимально долго игнорируют новое, а когда игнорировать становится невозможно - говорят, что оно просто "неудобное" и "непонятное"

Я для себя выбрал следующую механику работы в "Сложных" коллективах:
1️⃣ Подготовь все заранее.
2️⃣ Проведи обучение
3️⃣ Объяви пробный период.
4️⃣ Анонсируй обязательный переход на новые рельсы.
5️⃣ Если надо, дай отсрочку.(Возможно со второй сессией обучения)
6️⃣ Делай механизм обязательным.

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

Всем удачных и безболезненных внедрений. 📈

‼️Онлайн вебинар. Хранилище и Гит при разработке конфигурации‼️

Время проведения: Четверг 🕝02.02.2023 19.00 (по мск)

Добрый день!

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

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

Следите за новостями, ссылка на вебинар появится в четверг утром.

P.S. Если у вас есть вопросы по теме, на которые вы хотели бы услышать ответ, напишите их в комментариях, я постараюсь ответить на них на вебинаре

‼️Онлайн вебинар. Хранилище и Гит при разработке конфигурации‼️

Добрый день!

Сегодня в 19.00 состоится вебинар на тему использования хранилища и гит при командной разработке.

В рамках трансляции мы разберем основные способы работы с системами контроля версий конфигурации.

Трансляция будет доступна по ссылке

‼️ Хранилище и Гит при разработке конфигурации‼️

Уже в эфире! Как управлять релизами когда у вас много разработчиков?
Какие плюсы и минусы у каждого подхода?

Смотрите по ссылке

Добрый день!

Сегодня пост немного не по теме DevOps. Пост про интеграции.

Каждый в своей работе сталкивался с описанием интеграции с другими системами и наверняка видел прекрасные эксель-таблички для описания передаваемой в пакетах информации.
Я почти уверен, что вы знакомы с ситуацией, когда от вас ждут "тестовый JSON" для того чтобы начать тестировать интеграцию с другой системой. И тут вам приходится или рисовать его из головы, или в авральном темпе писать какие-то костыли для его генерации.
Ну а поддержание документации в актуальном виде после релиза... это для многих за гранью фантастики.

На самом деле, все можно поменять если перейти на описание спецификаций к вашим api по международному стандарту OpenApi. Отдавая информацию о вашем программном интерфейсе в таком виде, вы снимите большинство вопросов о том, как интегрироваться с вашей системой. А в процессе описания, с большой долей вероятности, наткнетесь на ошибки проектирования собственной системы.
Даже если вы интегрируетесь только в рамках своего предприятия и вам кажется что описание спецификации вашего апи это лишние трудозатраты, подумайте какие возможности дает такое описание для реализации авто-тестирования Апи или для его разработки.

Пишите в комментариях как вы сейчас описываете интеграции на текущем месте работы.

‼️Онлайн вебинар. OpenApi как, зачем и почему?‼️

Время проведения: Четверг 🕝16.02.2023 19.00 (по мск)

Добрый день!

Краткое содержание:
1️⃣ Бегло расскажу, что такое code-first и api-first подходы
2️⃣ Как описывать свой программный интерфейс так, чтобы это было понятно
3️⃣ Попробуем на примере создать документацию в прямом эфире
4️⃣ По документации реализуем наш маленький апи в проекте
5️⃣ Разберемся, что такое mock
6️⃣ Опубликуем нашу документацию, так, чтобы было не стыдно показать коллегам

➡️Ссылка на трансляцию!⬅️

Пишите вопросы, которые хотелось бы осветить в комментарии к этому посту

Добрый день.

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

В общем разбирать это руками - кошмарная задача.

Но что делать, когда необходимо собирать статистику, а объем тж даже за час невозможно загрузить в анализатор типа "инструментов разработчика"?
На помощь приходит выгрузка ТЖ в различные аналитические БД.

В качестве примера могу привести (слегка попиарюсь) свой проект по разбору ТЖ и выгрузке его в различные форматы.(я использую кликхаус, но можно выгружать и в другие системы)
ТЖ разбирается на различные потоки и выливается в разные таблицы аналитической БД.
С ней уже можно делать разные прекрасные манипуляции, например:
🟠 Получить статистику по виновникам таймаутов на блокировках за последний месяц(неделю, день) в разрезе контекстов исполнения
🟠Срез по контекстам возникновения ошибок

Установка парсера укладывается в 15-20 минут и дальше можно начинать работать!

А расскажите, какие методики анализа ТЖ вы используете в своей работе?

Добрый день.

Друзья, к сожалению, по личным обстоятельствам, мне придется перенести сегодняшний стрим. Прошу прощения у всех, кто ждал его сегодня.
Я обязательно проведу его в преддверии праздника. 22го февраля!

Прошу прощения за эти неудобства! Оставайтесь на связи!

Добрый вечер!

Старт вебинара уже через 10 минут!
Не пропустите!

Ссылка на трансляцию

Всем привет !
Заканчивается месяц интенсива и пора подводить итоги.

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

А пока я просто перечислю(Без разбивки по разным участникам) технологии ,которые мы внедрили за этот месяц:
1) Автоматический провиженинг виртуальных машин при помощи vagrant и ansible;
2) создание кластера docker-swarm;
3) прокси-сервер хранилища;
4) автоматическая выгрузка конфигурации в git;
5) статический анализ кода при помощи sonarQube;
6) интеграция gitlab и sonarQube для получения отчёта по статичесуому анализу;
7) автоматический прогон бдд тестов;
8) автоматический прогон smoke тестов;
9) интеграция jenkins и gitlab для запуска и получения результатов тестов;
10) интеграция jira и gitlab для автоматического транзишна задач при прохождении определенных стадий;
11) анализ технологического журнала, его выгрузка и сбор;
12) выгрузка журнала регистрации в clickhouse и его анализ в 1с;
13) выгрузка данных кластера 1c при помощи Prometheus+grafana настройка алертов;
14) интеграция Prometheus+grafana+ clickhouse и вывод для анализа и оповещений технологического журнала, журнала регистрации;
15) автоматическое создание файла поставки 1с по результатам тестирования и сохранения оного в хранилище артефактов.

Ну и попутно, для решения проблем были разобраны следующие вопросы:

1) программное лицензирование 1с в docker- контейнерах;
2) проброс аппаратных лицензий при помощи usb-over-ip технологий;
3) управление общими хранилищами данных;
4) работа с базами 1с при помощи vrunner;
5) разбор защищённого ssl подключения к контейнеру;
6) интеграция по rest с youtrack
И много-много мелких моментов которые возникали по ходу.

Что из этого списка вам бы хотелось внедрить у себя?

‼️Онлайн-интенсив "🥇Zero to hero. 2 поток" ‼️

Начинается прием заявок на новый поток DevOps-интенсива.

Команда растет и необходим контроль и осмысленное ведение разработки?
Хотите наладить мониторинг ваших систем для улучшения качества сервиса?
Пробуете автоматизировать контроль качества вашей разработки?

Не знаете с чего начать и как подступиться? Тогда вам ко мне!

🕝Старт: 20 марта

🔹 Мини-группа не больше 5 человек!
🔹 Индивидуальный план для каждого из участников!
🔹 Месяц личной работы со мной, консультаций и разборов возникающих вопросов.
🔹 Чат для решения любых вопросов. Ежедневная поддержка и ответы на возникающие проблемы.
🔹 Инструкции и методические материалы адоптированные конкретно под вас.
🔸 Ну и главное: Гарантированный результат!

За месяц интенсива вы добьетесь реальных результатов в автоматизации конкретно Вашего проекта.

Отзывы участников 1 потока говорят сами за себя!

💵Цена интенсива: 50000 рублей,

❗️Но для тех, кто оставит заявку и внесет предоплату до 14 марта, стоимость будет снижена на 20% до 40000 рублей❗️

➡️Оcтавляйте заявки⬅️