Надёжный Go-сервис в производстве — бесплатный тест онлайн

Вопрос 1 из 30

В рабочем примере по теме «Конфигурация» важно отделить гарантию от догадки. Как изменится состояние программы после этого фрагмента?

// Фрагмент для трассировки.
package main
import("errors";"time")
type Config struct{Timeout time.Duration}
func(c Config)Validate()error{if c.Timeout<=0{return errors.New("timeout must be positive")};return nil}
func main(){}

Снимок горутин показывает множество работников, ожидающих один и тот же мьютекс. Запись в общую карту без мьютекса из двух запросов создаёт гонку и может вызвать аварийное сообщение runtime. Сервис отказывается стартовать при неположительном таймауте, вместо аварии в первом запросе. Сигнал запускает `Shutdown`, а `ListenAndServe` возвращает `http.ErrServerClosed`, который не является аварией. При медленной базе фиксированный пул удерживает число запросов в пределах её ёмкости.

Вопрос 2 из 30

Фрагмент относится к теме «Конфигурация». Какое замечание на ревью будет наиболее точным?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("errors";"time")
type Config struct{Timeout time.Duration}
func(c Config)Validate()error{if c.Timeout<=0{return errors.New("timeout must be positive")};return nil}
func main(){}

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

Вопрос 3 из 30

На ревью разбирают тему «Конфигурация». Какое правило важнее случайных деталей конкретного запуска?

// Определите правило Go, которое объясняет результат.
package main
import("errors";"time")
type Config struct{Timeout time.Duration}
func(c Config)Validate()error{if c.Timeout<=0{return errors.New("timeout must be positive")};return nil}
func main(){}

Конфигурацию читают и валидируют до запуска рабочих горутин; секреты отделяют от безопасных параметров и не печатают целиком. Пакет должен явно заявлять конкурентную безопасность и владение фоновой работой; `Close` обязан иметь понятный повторный контракт. Параллельные тесты разделяют процесс, глобальные переменные и внешние ресурсы, поэтому изоляция должна быть явной. Параллельные запросы разделяют пул, а одна `Tx` обычно привязана к одному соединению и не является удобным общим объектом для независимых горутин. Middleware выполняется конкурентно для запросов; изменяемые счётчики, кеши и ограничители должны быть безопасны.

Вопрос 4 из 30

В разделе «Конфигурация» показан конкретный случай. Где корректный фрагмент легко становится ошибочным?

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

Вопрос 5 из 30

Команда проверяет решение по теме «Конфигурация». Что учитывать при выборе этого приёма для публичного API?

Больший параллелизм повышает пропускную способность до точки насыщения, после которой растут очереди и ошибки. Большой пул уменьшает локальное ожидание до предела базы, после которого ухудшает работу всех клиентов. Горячая перезагрузка уменьшает простой, но требует атомарного снимка и стратегии для параметров, которые нельзя менять безопасно. Жёсткие лимиты защищают ёмкость, но должны учитывать законные большие загрузки и потоковые ответы. Небольшие очереди быстрее проявляют перегрузку, а большие сглаживают краткие всплески ценой памяти и хвоста.

Вопрос 6 из 30

Фрагмент относится к теме «Метрики». Какой результат даст этот код на поддерживаемой реализации Go?

requests_total{method="GET",route="/users/:id",status="200"} 42
request_duration_seconds_bucket{route="/users/:id",le="0.5"} 40

Атомарный счётчик корректно считает входы без общей блокировки большой критической секции. Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен. Маршрут `/users/:id` используется как метка вместо фактического `/users/918273`. Сигнал запускает `Shutdown`, а `ListenAndServe` возвращает `http.ErrServerClosed`, который не является аварией. Десятки горутин могут ждать свободное соединение, даже если процессор почти не занят.

Вопрос 7 из 30

На ревью разбирают тему «Метрики». Что нужно поменять, чтобы граничный случай не превратился в сбой?

requests_total{method="GET",route="/users/:id",status="200"} 42
request_duration_seconds_bucket{route="/users/:id",le="0.5"} 40

Контекст проверки: Метрики.

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

Вопрос 8 из 30

В разделе «Метрики» показан конкретный случай. Какое свойство конструкции определяет её поведение?

requests_total{method="GET",route="/users/:id",status="200"} 42
request_duration_seconds_bucket{route="/users/:id",le="0.5"} 40

Вопрос относится к теме: Метрики.

Пакет должен явно заявлять конкурентную безопасность и владение фоновой работой; `Close` обязан иметь понятный повторный контракт. Метрики должны отвечать на вопросы о трафике, ошибках, задержке и насыщении; метки обязаны иметь ограниченную кардинальность. Ограничение параллелизма и пула соединений защищает и клиент, и удалённый сервис от лавины запросов. Конкурентный дефект может проявляться как редкая порча данных, рост горутин, взаимная блокировка или хвост задержки; нужен набор сигналов. Middleware выполняется конкурентно для запросов; изменяемые счётчики, кеши и ограничители должны быть безопасны.

Вопрос 9 из 30

Команда проверяет решение по теме «Метрики». Что стоит проверить до переноса решения в общий компонент?

Два последовательных этапа с собственными большими буферами могут скрыть минуты накопленной задержки. Идентификатор пользователя, полный URL или текст ошибки в метке создаёт неограниченное число временных рядов. Нулевые серверные таймауты оставляют процесс уязвимым для очень медленных клиентов. Финализатор не является надёжной заменой `Close` и не гарантирует своевременное освобождение. Неограниченный запуск горутин может исчерпать сокеты и память раньше, чем сработают таймауты.

Вопрос 10 из 30

Перед публикацией кода по теме «Метрики» нужно уточнить контракт. Как точнее всего описать пользу и цену этого решения?

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

Вопрос 11 из 30

На ревью разбирают тему «Корректное завершение». К какому результату приводит показанная конструкция?

// Фрагмент для трассировки.
package main
import("context";"net/http";"time")
func shutdown(s *http.Server){ctx,cancel:=context.WithTimeout(context.Background(),10*time.Second);defer cancel();_=s.Shutdown(ctx)}
func main(){}

Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен. Снимок горутин показывает множество работников, ожидающих один и тот же мьютекс. Сигнал запускает `Shutdown`, а `ListenAndServe` возвращает `http.ErrServerClosed`, который не является аварией. После сигнала сервис снимает readiness, вызывает `Shutdown` с дедлайном и ждёт работников. Семафор не позволяет одновременно выполнять больше двадцати внешних запросов.

Вопрос 12 из 30

В разделе «Корректное завершение» показан конкретный случай. Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("context";"net/http";"time")
func shutdown(s *http.Server){ctx,cancel:=context.WithTimeout(context.Background(),10*time.Second);defer cancel();_=s.Shutdown(ctx)}
func main(){}

Ограничивать кардинальность меток, контролировать очередь лимитера и не удерживать глобальную блокировку во время `next`. Не запускать скрытую вечную горутину без способа остановки, контекста и наблюдаемой ошибки. Ограничивать параллелизм, задавать контекст, отслеживать WaitCount/WaitDuration и избегать запросов N+1. Настраивать лимиты по профилю зависимости, иметь глобальный бюджет и корректно останавливать при выпуске. Иметь общий корневой контекст, идемпотентное закрытие, ограниченный льготный срок и принудительный финальный путь.

Вопрос 13 из 30

Команда проверяет решение по теме «Корректное завершение». На какой контракт языка или стандартной библиотеки здесь нужно опереться?

// Определите правило Go, которое объясняет результат.
package main
import("context";"net/http";"time")
func shutdown(s *http.Server){ctx,cancel:=context.WithTimeout(context.Background(),10*time.Second);defer cancel();_=s.Shutdown(ctx)}
func main(){}

`Server.Shutdown` прекращает приём новых соединений и ждёт активные обработчики в пределах контекста. Параллельные запросы разделяют пул, а одна `Tx` обычно привязана к одному соединению и не является удобным общим объектом для независимых горутин. Завершение — протокол: перестать принимать новую работу, отменить фоновые задачи, дождаться активных операций и закрыть зависимости. Пакет должен явно заявлять конкурентную безопасность и владение фоновой работой; `Close` обязан иметь понятный повторный контракт. Параллельные тесты разделяют процесс, глобальные переменные и внешние ресурсы, поэтому изоляция должна быть явной.

Вопрос 14 из 30

Перед публикацией кода по теме «Корректное завершение» нужно уточнить контракт. Какое ограничение опаснее всего пропустить?

Два последовательных этапа с собственными большими буферами могут скрыть минуты накопленной задержки. Неограниченный fan-out к базе превращает краткий всплеск в очередь и каскад таймаутов. Если сначала закрыть базу, активные HTTP-запросы могут завершиться ошибкой вместо штатного окончания. Бесконечный обработчик или зависшая фоновая горутина могут пережить срок `Shutdown`. `t.Setenv` нельзя безопасно сочетать с параллельным тестом, потому что окружение общее для процесса.

Вопрос 15 из 30

В рабочем примере по теме «Корректное завершение» важно отделить гарантию от догадки. Какой вывод о сопровождении решения наиболее взвешенный?

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

Вопрос 16 из 30

В разделе «Расследование сбоя» показан конкретный случай. Как завершится показанный фрагмент при указанных входных данных?

12:01 deploy v1242
12:03 p99 180ms -> 4.8s
12:03 db_in_use 20/20
12:04 db_wait_duration +38s/s
12:05 cpu 31%

Рост `db.WaitDuration` одновременно с исчерпанием пула указывает на очередь за соединениями, а не на нехватку CPU. Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен. Семафор не позволяет одновременно выполнять больше двадцати внешних запросов. Десятки горутин могут ждать свободное соединение, даже если процессор почти не занят. Снимок горутин показывает множество работников, ожидающих один и тот же мьютекс.

Вопрос 17 из 30

Команда проверяет решение по теме «Расследование сбоя». Что здесь следует изменить прежде всего?

12:01 deploy v1242
12:03 p99 180ms -> 4.8s
12:03 db_in_use 20/20
12:04 db_wait_duration +38s/s
12:05 cpu 31%

Контекст проверки: Расследование сбоя.

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

Вопрос 18 из 30

Перед публикацией кода по теме «Расследование сбоя» нужно уточнить контракт. Какое правило отделяет верный разбор от правдоподобной догадки?

12:01 deploy v1242
12:03 p99 180ms -> 4.8s
12:03 db_in_use 20/20
12:04 db_wait_duration +38s/s
12:05 cpu 31%

Вопрос относится к теме: Расследование сбоя.

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

Вопрос 19 из 30

В рабочем примере по теме «Расследование сбоя» важно отделить гарантию от догадки. Какой крайний случай обязан попасть в тесты?

Автоматическая публикация `/debug/pprof` без защиты раскрывает внутреннее состояние сервиса. Неограниченный запуск горутин может исчерпать сокеты и память раньше, чем сработают таймауты. Среднее значение может скрыть ухудшение p99 и ошибки небольшой, но важной группы запросов. Финализатор не является надёжной заменой `Close` и не гарантирует своевременное освобождение. Два последовательных этапа с собственными большими буферами могут скрыть минуты накопленной задержки.

Вопрос 20 из 30

Фрагмент относится к теме «Расследование сбоя». Какой выбор лучше отражает баланс простоты и контроля?

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

Вопрос 21 из 30

Команда проверяет решение по теме «Тестирование и наблюдаемость» в тесте «Надёжный Go-сервис в производстве». Как изменится состояние программы после этого фрагмента?

release:
  canary_percent: 5
  abort_if:
    error_rate: "> 1%"
    p99: "> 800ms"

Тест отменяет контекст после первого результата и убеждается, что выход закрывается за ограниченное время. Канареечный выпуск останавливается, когда доля 5xx и p99 выходят за заранее заданный бюджет. `t.TempDir()` создаёт изолированный каталог и автоматически удаляет его после теста. Точный итог счётчика и чистый `-race` проверяют разные стороны: смысл и отсутствие обнаруженной гонки. Специальный `Reader` с одним байтом за вызов проверяет, что функция не рассчитывает на заполнение буфера сразу.

Вопрос 22 из 30

Перед публикацией кода по теме «Тестирование и наблюдаемость» нужно уточнить контракт в тесте «Надёжный Go-сервис в производстве». Какое замечание на ревью будет наиболее точным?

release:
  canary_percent: 5
  abort_if:
    error_rate: "> 1%"
    p99: "> 800ms"

Контекст проверки: Тестирование и наблюдаемость.

Добавлять компиляционные проверки допустимых типов и обычные поведенческие тесты граничных значений. Определить SLO, проверку готовности, тревоги по расходу бюджета ошибок и автоматический откат с ручным подтверждением опасных миграций. Использовать короткий контролируемый таймаут, синхронизацию запуска и отдельную проверку причины завершения. Использовать барьеры вместо сна, запускать `-race` и отслеживать число горутин до и после серии операций. Выносить проверку паники в небольшую функцию и добавлять `debug.Stack()` в журнал на эксплуатационной границе.

Вопрос 23 из 30

В рабочем примере по теме «Тестирование и наблюдаемость» важно отделить гарантию от догадки в тесте «Надёжный Go-сервис в производстве». Какое правило важнее случайных деталей конкретного запуска?

release:
  canary_percent: 5
  abort_if:
    error_rate: "> 1%"
    p99: "> 800ms"

Вопрос относится к теме: Тестирование и наблюдаемость.

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

Вопрос 24 из 30

Фрагмент относится к теме «Тестирование и наблюдаемость» в тесте «Надёжный Go-сервис в производстве». Где корректный фрагмент легко становится ошибочным?

Чистый отчёт не доказывает отсутствие непокрытой гонки; найденный отчёт нельзя «лечить» случайным `Sleep`. Разница в несколько процентов может быть шумом частоты процессора, фоновой нагрузки или компоновки памяти. Зелёный health endpoint внутри процесса не доказывает доступность базы, очереди и внешнего маршрута. Тесты только внутри пакета могут случайно зависеть от деталей, недоступных реальному пользователю. Тест может пройти много раз при наличии гонки; отсутствие отчёта в одном запуске не является доказательством.

Вопрос 25 из 30

На ревью разбирают тему «Тестирование и наблюдаемость» в тесте «Надёжный Go-сервис в производстве». Что учитывать при выборе этого приёма для публичного API?

Глубокая readiness точнее отражает способность обслуживать, но слишком дорогая проверка сама может перегрузить зависимости. Случайный порядок ловит зависимость тестов, но найденную нестабильность нужно устранить, а не просто повторять до успеха. Наблюдаемость очереди помогает увидеть давление, но вмешательство в протокол ради метрики способно создать новые гонки. Отдельная диагностика улучшает уверенность, но тест не должен зависеть от случайного порядка для прохождения. Автоматический порог ловит регрессии, но слишком жёсткий предел создаёт нестабильный CI и привыкаемость к тревогам.

Вопрос 26 из 30

Перед публикацией кода по теме «Конкурентность и эксплуатация» нужно уточнить контракт. Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package main
const maxConcurrent=64
var slots=make(chan struct{},maxConcurrent)
func guarded(fn func()error)error{select{case slots<-struct{}{}:defer func(){<-slots}();return fn();default:return ErrBusy}}
var ErrBusy=errorString("busy")
type errorString string
func(e errorString)Error()string{return string(e)}
func main(){}

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

Вопрос 27 из 30

В рабочем примере по теме «Конкурентность и эксплуатация» важно отделить гарантию от догадки. Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
const maxConcurrent=64
var slots=make(chan struct{},maxConcurrent)
func guarded(fn func()error)error{select{case slots<-struct{}{}:defer func(){<-slots}();return fn();default:return ErrBusy}}
var ErrBusy=errorString("busy")
type errorString string
func(e errorString)Error()string{return string(e)}
func main(){}

Сочетать лимит параллелизма, отмену, предохранитель от серии ошибок и метрики насыщения пула. Не запускать скрытую вечную горутину без способа остановки, контекста и наблюдаемой ошибки. Настраивать лимиты по профилю зависимости, иметь глобальный бюджет и корректно останавливать при выпуске. Ограничивать кардинальность меток, контролировать очередь лимитера и не удерживать глобальную блокировку во время `next`. Связать лимиты HTTP, пула базы и внешних клиентов; следить за горутинами, памятью, паузами GC и очередями.

Вопрос 28 из 30

Фрагмент относится к теме «Конкурентность и эксплуатация». Какое свойство конструкции определяет её поведение?

// Определите правило Go, которое объясняет результат.
package main
const maxConcurrent=64
var slots=make(chan struct{},maxConcurrent)
func guarded(fn func()error)error{select{case slots<-struct{}{}:defer func(){<-slots}();return fn();default:return ErrBusy}}
var ErrBusy=errorString("busy")
type errorString string
func(e errorString)Error()string{return string(e)}
func main(){}

Число работников, размер буфера и политика повторов образуют единую систему управления нагрузкой. Ограничение параллелизма и пула соединений защищает и клиент, и удалённый сервис от лавины запросов. Middleware выполняется конкурентно для запросов; изменяемые счётчики, кеши и ограничители должны быть безопасны. Надёжность требует ограниченных очередей, бюджетов времени, контролируемых повторов и владельца каждой горутины. Пакет должен явно заявлять конкурентную безопасность и владение фоновой работой; `Close` обязан иметь понятный повторный контракт.

Вопрос 29 из 30

На ревью разбирают тему «Конкурентность и эксплуатация». Что стоит проверить до переноса решения в общий компонент?

Два последовательных этапа с собственными большими буферами могут скрыть минуты накопленной задержки. Повтор на каждом слое умножает попытки: три слоя по три попытки могут превратить один запрос в 27 обращений. Неограниченный fan-out к базе превращает краткий всплеск в очередь и каскад таймаутов. Бесконечный обработчик или зависшая фоновая горутина могут пережить срок `Shutdown`. Мьютекс, удерживаемый вокруг `next`, последовательно обработает весь сервер и может привести к взаимной блокировке.

Вопрос 30 из 30

В разделе «Конкурентность и эксплуатация» показан конкретный случай. Как точнее всего описать пользу и цену этого решения?

Длинный льготный срок сохраняет запросы, но замедляет выпуск и может удерживать старую версию слишком долго. Запас ёмкости переживает всплеск, но постоянная работа у предела лишает систему пространства для восстановления. Небольшие очереди быстрее проявляют перегрузку, а большие сглаживают краткие всплески ценой памяти и хвоста. Большой пул уменьшает локальное ожидание до предела базы, после которого ухудшает работу всех клиентов. Жёсткие лимиты защищают ёмкость, но должны учитывать законные большие загрузки и потоковые ответы.