Что я узнал, работая в федеральном веб-отделе
На следующей неделе будет моя последняя неделя по контракту. Я решил уйти, и прежде чем двигаться дальше, я хотел записать, чем я на самом деле занимался изо дня в день.
Я не был прямым сотрудником агентства. Я работал на подрядчика, назначенного в программу агентства в качестве технического руководителя / архитектора. Это схема, лежащая в основе многих федеральных веб-работ. Вы ежедневно в команде, но ваша зарплата поступает из другого места.
Перед началом работы был процесс получения допуска. Проверка биографии, формы, рекомендации, ожидание. Это стандартно для федеральных контрактных работ и формирует процесс адаптации больше, чем большинство частных компаний.
Чем я на самом деле занимался
Большую часть времени я уделял общедоступным контентным сайтам. Тысячи страниц, миллионы посетителей, контент на нескольких языках. Большинство переводов обрабатывались сторонним сервисом, MotionPoint. Несколько сайтов использовали встроенный перевод Drupal вместо этого для испанского, китайского и корейского вариантов. Каждый имел свои особенности, связанные с локализованными URL-адресами и различными системами письма.
Большая часть работы заключалась в поддержании работоспособности портфеля существующих сайтов Drupal. Обновления версий, модулей, исправления и работа над функциями. Я также участвовал в более крупном проекте по консолидации более 400 сайтов Drupal в 8 хабов. Этот проект все еще находится в стадии реализации.
Я проводил аудиты. Инвентаризация тысяч PDF-файлов. Проверка доступности. Поиск битых ссылок и устаревшего контента. Большая часть этой ручной работы превратилась в скрипты Python. Аудиты PDF, выгрузки аналитики, парсеры, проверки перенаправлений, генераторы отчетов. Команда до сих пор использует некоторые из них.
Я также поддерживал команду аналитики данных. GA4, Google Search Console и GTM. Выгрузка отчетов, исправление проблем с тегами, расследование расхождений и синхронизация отслеживания с изменениями на сайте. Я также автоматизировал часть генерации отчетов на Python.
Первое, чем я занялся, был процесс развертывания. Большая его часть уже работала на Jenkins, но один критический шаг все еще требовал, чтобы кто-то запускал скрипт оболочки со своего ноутбука. Перенос этого последнего шага на Jenkins стал моей первой победой.
Позже я добавил CodeDeploy для нижних сред, чтобы ускорить развертывание там. К концу развертывание, которое раньше занимало более часа, выполнялось за несколько минут.
Дежурство по вызовам было частью работы. Проблемы на производстве не ждут рабочего времени.
Я также потратил время на платформу для синдикации контента вне нашего основного стека. Основана на Grails, старая, я раньше с ней не работал. Groovy, который я писал для конвейеров Jenkins, пригодился, что сделало освоение платформы быстрее, чем могло бы быть иначе. Я изучил ее достаточно хорошо, чтобы устранять неполадки, и помог с обновлением сервера до Ubuntu 22.04.
Несколько других вещей, к которым я прикоснулся.
- Два приложения React, небольшие фронтенд-компоненты, наложенные поверх CMS и связанные с федеральной системой дизайна.
- AWS изо дня в день. Балансировщики нагрузки, группы целей, CodeDeploy и значительное количество отладки производственных проблем, которые проявляются только при реальном трафике.
- Тестирование с помощью Playwright и Cypress, pytest для Python. Ближе к концу я экспериментировал с Playwright и LLM для обнаружения визуальных регрессий, которые обычные сравнения упускают.
- Демонстрации и прототипы AI, показывающие руководству, что могут современные инструменты и как они могут вписаться, не вызывая проблем с безопасностью.
Стек включал Drupal, PHP, Python, JavaScript, React, Groovy, Jenkins, Docker, AWS, Splunk и USWDS (US Web Design System). К концу также появилось много AI-инструментов (Gemini, OpenAI, векторные базы данных, MCP-серверы).
Несколько вещей, которые я заметил
Процесс — это реальность. Обзоры безопасности, аудиты доступности, заморозки контента, планирование спринтов между командами. В первый месяц это казалось медленным. Затем вы понимаете, зачем это нужно.
Jira, Confluence и Bitbucket были размещены локально для соответствия требованиям FedRAMP. Облачные версии не были вариантом.
Много встреч. Стендапы, планирование спринтов, обзоры архитектуры, обзоры контента, синхронизации команд, индивидуальные встречи, демонстрации, отчеты о статусе. Некоторые были необходимы. Некоторые — нет.
Доступность — это не галочка. Она меняет то, как вы называете вещи, структурируете страницы и тестируете.
Редакторы и руководители программ были большой частью тех, с кем я работал изо дня в день, а не только другие инженеры.
Вы работаете со многими внешними поставщиками. Akamai для CDN и защиты на границе, партнер AWS для инфраструктуры, GSA для интеграции search.gov и различные поставщики аудита и обзоров по пути. Реальная часть работы — это поиск ответов за пределами вашей команды, а не только внутри нее.
Коммуникация — большая часть работы. Вероятно, больше, чем я ожидал.
Я много писал. Отчеты о статусе, руководства по эксплуатации, документы для передачи, тикеты. Я буквально пишу электронное письмо для передачи, пока печатаю это.
Много времени ушло на объяснение технических компромиссов людям, которые не являются техническими специалистами.
Ближе к концу я занимался AI. Рабочие процессы с помощью AI, классификаторы LLM для PDF и MCP-серверы. Мы также начали переговоры о включении кодирующих агентов, таких как Codex и Claude Code, в наш рабочий процесс. Эти одобрения все еще ожидают рассмотрения со стороны правительства.
Отладка в облаке — это отдельная история. Производство AWS не похоже на ваш ноутбук. Вы проводите много времени в Splunk, CloudWatch и истории развертываний.
Мне посчастливилось руководить умными людьми и работать с менеджером, который доверял мне выполнять работу. Это облегчило большую часть остального.
Вот и все. Перехожу к следующему.