Сценарий применения LLM из личного опыта

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

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

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

Нужно настроить какой-то мониторинг с алёртингом и автоматизировать восстановление инфраструктуры. Но и этим заниматься некому и некогда.

Нагрузить «того парня», виртуального.

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

Далее 10 минут на выяснение, как лучше реализовать скрипт мониторинга, оповещение в Telegram-чат, как это всё лучшим образом «присоседить», как получать логи и как «вручную» из скрипта поднимать упавшие намертво контейнеры.

На выходе были получены все инструкции и готовый Python-скрипт.

Следующие 20 минут ушли на настройку, интеграцию и первичные тесты.

Итого на решение проблемы понадобилось 30 мин ⏲

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

Потрачено минимум усилий, и все довольны. На всё про всё для решения простой DevOps-задачи потребовался один Unity-разработчик на полчаса. Далее уже по мере высвобождения ресурсов можно будет заменить свою поделку на какой-нибудь полноценный Zabbix.

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

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

Чтобы реализовать эту задачу всё равно нужны базовые знания Linux-систем, Docker'а и синтаксиса Python. Благо это стандартный набор для любого разработчика. А разные языки вообще полезно периодически прощупывать, особенно из числа популярных.

Напоминаю, что игровая разработка одним только Unity не ограничивается. Например, мне на этой неделе HR прислал вакансию со стеком: Unity, SRP, ECS, Burst, Job System, клиент-сервер, PostgreSQL, Teamcity, Dapper, Prometheus, Grafana. А клиент-сервер – это сразу Linux и Docker.

Вакансия на Tech Lead. Но:

Для вертикального роста по-хорошему крепкий Middle уже должен быть хоть немного знаком с клиент-сервером, Linux, Docker, CI и уметь разбираться в коде на других языках. Как минимум тех, которые используются на целевых платформах разработки.

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

————————————

#gamedev #development #llm #ai #experience #case #devops #monitoring #backend #infrastructure #геймдев #разработка #опыт #ии #ситуация #мониторинг #инфраструктура #бэкенд #aks2dio