Большинство портфолио разработчиков — статические сайты. У моего есть SLO.
Речь не о переусложнении. Речь о демонстрации конкретного навыка, который сложно показать на собеседованиях: операционной зрелости.
Что значит «production-уровневое портфолио»
Мой сайт-портфолио (sageideas.dev) включает:
- Целевые SLO: 99,9% доступности панели управления, свежесть телеметрии <24ч, P95 время ответа <500мс
- Учения по инцидентам: 4 сценария сбоев с задокументированными реакциями
- WAF-ограничение запросов: CloudFront Web ACL с доказательствами симуляции атак
- OIDC-федерация: GitHub Actions → AWS без статических учетных данных
- Качественная телеметрия: Живая панель, загружающая CI-артефакты в реальном времени
- Подтверждения безопасности: IAM-политики, модели угроз и доказательства для каждого утверждения
Зачем это нужно?
Потому что разрыв между «я умею создавать» и «я умею эксплуатировать» — это территория senior-ролей.
Джуниоры создают функции. Мидлы создают системы. Сеньоры эксплуатируют системы — они думают о сценариях отказов, радиусе поражения, стоимости, соответствии требованиям и о том, что случится в 3 часа ночи.
Относясь к своему портфолио как к production-системе, я показываю:
- Я думаю о сбоях до их возникновения — у каждой внешней зависимости есть запасной вариант
- Я измеряю то, что важно — SLO, а не тщеславные метрики
- Я документирую для следующего человека — runbook'и, playbook'и, архитектурная документация
- Я не срезаю углы в безопасности — даже для сайта-портфолио
Шаблон учений по инцидентам
Каждый квартал я прохожу 4 сценария:
| Сценарий | Реакция | Статус |
|---|---|---|
| GitHub API rate limits | Переключение в режим снимка | Проверено |
| Отсутствующий CI-артефакт | Сканирование последних запусков, плавная деградация | Проверено |
| Несоответствие токена AWS proxy | CloudWatch-аларм, автоматическая деградация | Проверено |
| Отсутствующий объект S3 | Закрытый сбой, утечка секретов исключена | Проверено |
Каждое учение следует схеме: обнаружение → триаж → смягчение → проверка → документирование
Отчет об учениях публично доступен в моей библиотеке артефактов.
Что замечают нанимающие менеджеры
Когда я прохожу собеседования на senior/staff-позиции, я не говорю о дизайне портфолио. Я говорю о его эксплуатации:
- «Вот моя SLO-панель. В этом месяце мы на 99,94%.»
- «Вот тест WAF-ограничения запросов, который я провел на прошлой неделе. 429-е ошибки срабатывают при 100 запросах за 5 минут.»
- «Вот IAM-политика. У Lambda ровно одно разрешение: s3:GetObject на один ключ.»
Это меняет разговор с «умеешь ли ты кодить?» на «умеешь ли ты эксплуатировать системы?» — а это именно то, что требуется на позициях от $200K+.
Как сделать это самостоятельно
Вам не нужен AWS. Начните с малого:
- Определите один SLO — «В этом месяце uptime моего сайта будет 99%». Отслеживайте его.
- Добавьте один шлюз качества — Lighthouse CI в пайплайне деплоя. Останавливайте сборку, если производительность падает.
- Задокументируйте один сценарий отказа — «Что произойдет, если истечет мой API-ключ?» Запишите ответ.
- Проведите одно учение по инциденту — Намеренно сломайте что-то и отработайте реакцию.
Цель не в совершенстве. Цель — показать, что вы думаете о production, а не только о разработке.
Связанная система: Что на самом деле строит AI-native студия объясняет, почему портфолио одновременно рассматривается как поверхность продукта, операционная система и цикл роста.
