интенсивность
2 урока в неделю
когда
27 октября
необходимый грейд
middle/senior
длительность
1.5 месяца
Ты — новый Golang разработчик в traveltech компании
Развиваешь существующий сервис бронирования отелей, а там...
Падение одного микросервиса рушит всю систему, БД отказывает на пиковых нагрузках, и сбои — постоянная головная боль
Готовый номер считается неготовым
Room-ready событие отстаёт за медленным consumer
Гость: ждет
Отель: медленный check-in
Бронь есть, события нет
DB commit прошёл, а публикация в Kafka — нет
Гость: нет подтверждения
Стойка: бронь не видна
Истечение кеша обрушает PostgreSQL
Одинаковые miss одновременно идут в Search DB
Гость: ошибка поиска
Система: DB Saturation
Два гостя получают один номер
Конкурентные запросы уменьшают один остаток без проверки версии
Гость: отменяет бронь
Отель: овербукинг
Availability блокирует Booking
Ожидание и повторы заполняют connections и создают каскадный отказ
Гость: spinner
Платформа: retry storm
Система принимает больше работы, чем завершает
Низкоприоритетный поиск заполняет очередь и вытесняет check-in
Гость: не заселяется
Отель: очередь в лобби
Повтор создаёт вторую бронь
Booking сохранил результат, но клиент не получил ответ
Гость: две брони
Отель: ручная сверка
Популярный отель перегружает поиск
Тысячи гостей проверяют один номер на одинаковые даты
Гость: виснет поиск
Отель: теряет брони
Глядя на архитектуру сервиса, возникают вопросы:
/1
Упал один микросервис, а за ним вся система. Как разорвать цепочку
/2
БД легла от всплеска запросов. Как правильно использовать кэш, чтобы оптимизировать хранение данных
/3
В момент дежурства упала система. Как найти быстро найти причину, и какие действия предпринять для ее устранения без помощи старших коллег
/4
Как правильно кэшировать данные, чтобы не получить тонны устаревшей информации при инвалидации кеша или падении Redis
/5
Как написать повторную обработку сообщений, которая гарантированно не сломает систему
/6
Как правильно использовать retry, чтобы он за минуты при нагрузке не положил прод
чтобы решить задачу:
Вместе c Senior из Ozon Tech поочередно рассмотришь все проблемы в коде, к каждой разберешь теорию и сразу напишешь best practice решение
Непонятно, где случился инцидент
как исправим:
Дашборды в Grafana • алерты в Prometheus
Заранее можем прогнозировать проблемы, а если случился инцидент — быстро найти его
Готовый номер продолжает считаться неготовым
как исправим:
Message key · manual offset · lag SLI
События упорядочены по room_id, offset фиксируется после обработки, lag измеряется во времени
Бронь сохранена, но событие не опубликовано
как исправим:
Transactional outbox · inbox · retry topics
Booking пишет outbox вместе с бронью; consumer дедуплицирует доставку через inbox
Одновременные cache miss обрушивают Search DB
как исправим:
Singleflight · soft/hard TTL · TTL jitter
Один запрос обновляет ключ, остальные получают soft-stale. Hard TTL разнесён jitter
Два гостя резервируют последний номер
как исправим:
Optimistic locking · CAS · version token
Availability обновляет остаток только при совпадении версии
Availability блокирует Booking и создаёт retry storm
как исправим:
Deadline · timeout · circuit breaker · retry budget
Общий deadline ограничивает цепочку, breaker прекращает бесполезные вызовы
Поиск вытесняет check-in при нагрузке выше capacity
как исправим:
Load shedding · priority admission · bounded queue
Gateway отдаёт 429 низкому приоритету и сохраняет отдельный бюджет для check-in
Повтор запроса создаёт вторую бронь
как исправим:
Idempotency-Key · stored result
Booking хранит ключ и результат в транзакции с бронью и возвращает тот же ответ
Популярный отель перегружает Search
как исправим:
Cache-aside · hot-key isolation
Search владеет Redis, объединяет одинаковые запросы и возвращает допустимый stale-result
В итоге получишь «рецепты» по решению типичных инцидентов в prod’e, которые применимы к любой сфере и размеру компании — от маленькой до BigTech
подойдет middle/senior go-разработчикам
знаешь основы kafka
базово владеешь redis
Джунам будет сложно, но полезно
Если хочется быстрее расти и не пугает, что для усвоения материала придется дополнительно поизучать какие-то темы — приходи
подробная программа
Попадешь в смоделированную TravelTech-компанию: микросервисная архитектура с десятками типичных проблем в коде. Каждый урок закрывает один инженерный вопрос — почему возникает отказ, как его заметить и какой паттерн применить
{
ффф"ratio": {
ффффф"practice": 80%,
ффффф"theory": 20%
ффф}
}
ффф"ratio": {
ффффф"practice": 80%,
ффффф"theory": 20%
ффф}
}
Начинаем с инженерного расследования: почему пользователь видит ошибку, где искать источник деградации и как по метрикам отличить частичный отказ от каскадного
Теория:
Практика:
----------------------
Результат:
Теория:
- архитектура учебного Go-стенда в Kubernetes: gateway, несколько микросервисов, БД, брокер или кэш;
- надежность vs отказоустойчивость, graceful degradation, blast radius, MTBF и MTTR;
- partial failure, cascading failure, transient, permanent и intermittent failures;
- почему сеть ненадежна: timeout, потерянный ответ, частичный успех и отсутствие глобального времени;
- SLI / SLO / SLA: availability, error rate, latency p95/p99, saturation и request rate;
- почему средняя latency обманывает и как читать пользовательскую деградацию по p95/p99.
Практика:
- в k8s-стенде включаем fault-сценарии: сломанный pod, медленный downstream, временно недоступную БД и lag в асинхронной обработке
- работаем с Grafana / Prometheus, kubectl, логами и incident card.
----------------------
Результат:
- умеешь начать расследование: найти симптом, определить пострадавший SLI, оценить радиус поражения и выбрать первую безопасную реакцию
Retry и Circuit Breaker — это база. Но сначала сервис должен правильно стартовать, попадать в балансировку, переживать rolling update и корректно завершать in-flight запросы
Теория:
Практика:
----------------------
Результат:
Теория:
- pod lifecycle в Kubernetes: старт контейнера, регистрация endpoint, service routing и удаление pod из трафика;
- startupProbe, readinessProbe, livenessProbe: назначение, различия и типичные ошибки;
- почему liveness не должна проверять внешнюю БД, брокер или соседний сервис;
- safe rolling update: maxUnavailable, maxSurge, capacity во время деплоя и rollback;
- SIGTERM, preStop, terminationGracePeriodSeconds, drain in-flight requests и закрытие соединений;
- метрики деплоя: 5xx rate, p95/p99 latency, pod restarts, ready pods, in-flight requests и rollout duration.
Практика:
- запускаем k6;
- выкатываем плохую версию и видим 5xx/timeout в Grafana;
- исправляем probes, graceful shutdown и rolling update;
- повторяем rollout и сравниваем показатели до/после.
----------------------
Результат:
- понимаешь, как доказать метриками, что сервис переживает деплой без пользовательских ошибок и не усиливает инцидент перезапусками
Retry действительно помогают при временных сбоях, но без бюджета, backoff, jitter и идемпотентности они превращаются в усилитель аварии. В этом уроке учимся писать безопасную повторную обработку
Теория:
Практика:
----------------------
Результат:
Теория:
- когда retry уместен, а когда он только ухудшает ситуацию;
- fixed, linear, exponential backoff и exponential backoff with jitter;
- синхронизация клиентов, retry amplification и восстановление после даунтайма;
- retry budget и retry circuit breaker как ограничители дополнительной нагрузки;
- Idempotency-Key, хранение результата, TTL ключей и защита от повторного списания денег;
- fingerprint / versioning для синхронизации клиента и сервера после потери ответа.
Практика:
- добавляем retry budget и идемпотентность в API создания заказа
----------------------
Результат:
- умеешь писать повторные попытки, которые не создают лавину трафика и не дублируют бизнес-операции
Разбираемся, когда ждать, отменять, размыкать цепь, и как сохранить пользовательский сценарий через деградацию
Теория:
Практика:
----------------------
Результат:
Теория:
- ail latency, p95/p99 и hedging requests для борьбы со случайными задержками;
- риски hedging: дополнительная нагрузка, отмена дублей, приоритет hedge-запросов;
- connection timeout, request timeout и выбор порогов по latency-метрикам;
- timeout propagation и deadline в цепочке вызовов HTTP/gRPC;
- circuit breaker: состояния closed / open / half-open, сбор статистики, поколения и настройка порогов;
- fallback, cached fallback, stub response, feature flag degradation и частичная функциональность;
- runtime feature flags через etcd: локальный snapshot, watch-обновления, kill switch и безопасный fallback при недоступности config storage.
Практика:
- внедряем timeout propagation, circuit breaker и degraded response между сервисами
----------------------
Результат:
- можешь спроектировать синхронный вызов так, чтобы зависший downstream не забирал всю систему за собой
Защищаем ресурсы до того, как сервис начнет падать: отделяем критичные участки, ограничиваем входящий / исходящий трафик и учимся честно отвечать клиенту при исчерпанной квоте
Теория:
Практика:
----------------------
Результат:
Теория:
- bulkhead: isolation, limitation, reservation и защита от resource starvation;
- goroutine / worker pool, semaphore, HTTP connection pool и database connection pool;
- process / container bulkhead, sidecar, физическую изоляцию и Kubernetes requests / limits;
- client-side, server-side и distributed rate limiter;
- token bucket, leaky bucket, fixed window и sliding window counter;
- 429, Retry-After, X-RateLimit headers, мониторинг лимитов и риски SPOF в distributed limiter;
- где ставить лимит: приложение, SDK, sidecar, gateway, ingress или балансировщик.
Практика:
- реализуем rate limiter и проверяем его поведение под стресс-нагрузкой
----------------------
Результат:
- умеешь ограничивать blast radius медленной ручки, noisy neighbor и внезапной волны трафика
Когда система уже близка к перегрузке, простой лимит RPS не спасает. Учимся управлять очередями, latency, приоритетами и сознательно отбрасывать лишнее ради выживания ядра
Теория:
Практика:
----------------------
Результат:
Теория:
- backpressure: buffering, dropping и control как три стратегии работы с избытком данных;
- разницу backpressure в асинхронной и синхронной моделях;
- TCP sliding window, advertised window, zero window, slow start и Vegas TCP как основу мышления;
- load shedding: simple, partitioned и percentage strategies;
- разницу rate limiter и load shedder: квоты против текущего состояния системы;
- выбор лимита через latency, очередь, CPU, errors и закон Литтла;
- адаптивное окно обработки и агрессивное снижение нагрузки при timeout / reject.
Практика:
- внедряем load shedding middleware и наблюдаем пределы сервиса на нагрузке
----------------------
Результат:
- понимаешь, когда лучше отказать части запросов, чем позволить очереди разрушить весь сервис
Разбираемся, где появляется порядок, как масштабируются consumer groups и почему offset является состоянием обработки
Теория:
Практика:
----------------------
Результат:
Теория:
- Kafka как распределенный лог: brokers, topics, partitions, records и keys;
- порядок сообщений внутри партиции и выбор key для сущности;
- producer: partitioning, acks=0/1/all, min.insync.replicas, retries и enable. idempotence;
- consumer groups, rebalance, current offset, committed offset и current position;
- __consumer_offsets, group coordinator и log compaction;
- auto-commit, manual commit, sync / async commit и их влияние на потери / дубли;
- at-most-once, at-least-once, exactly-once и почему «ровно один раз» требует оговорок.
Практика:
- настраиваем producer / consumer и проверяем сценарии потерь и дублей
----------------------
Результат:
- понимаешь, какие гарантии Kafka дает сама, а какие обязан обеспечить твой код
Разбираемся, как не потерять событие между БД и Kafka, как пережить дубли, что делать с poison messages и когда inbox важнее простой производительности
Теория:
Практика:
----------------------
Результат:
Теория:
- почему запись в БД и отправка в Kafka не являются одной транзакцией;
- transactional outbox: сущность + событие в одной транзакции и relay-процесс;
- consumer idempotency, message_id, order_id, event_type и created_at;
- consumer group lag, partition skew и причины роста отставания;
- transient, permanent и poison messages;
- retry topics, backoff-цепочки, metadata сообщения, retry amplification и DLQ;
- нарушение порядка при retry topics и inbox-паттерн для контроля обработки.
Практика:
- внедряем outbox, обработку дублей, retry topic, DLQ и inbox
----------------------
Результат:
- умеешь проектировать обработку сообщений так, чтобы дубли и ошибки были штатной ситуацией, а не аварией
Кэш ускоряет систему, но легко начинает отдавать старые данные. Разбираем согласованность, инвалидацию и конкурентные обновления до того, как кэш станет источником инцидентов
Теория:
Практика:
----------------------
Результат:
Теория:
- почему возникают stale data: batch refresh, partial failures, race condition и async replication;
- TTL-based approach: когда он подходит и где не дает гарантий актуальности;
- cache-aside, write-around, write-through и компромисс latency/consistency;
- синхронную инвалидацию и событийную инвалидацию через broker, invalidator, CDC и outbox;
- lost update и конкурентную модификацию данных в Redis;
- explicit lock, optimistic lock, Redis WATCH/MULTI/EXEC, CAS и version tokens;
- как выбрать подход по уровню конкуренции, цене stale data и профилю записи.
Практика:
- исправляем race condition и строим безопасную инвалидацию
----------------------
Результат:
- можешь выбрать стратегию кэша не только по скорости, но и по допустимой рассинхронизации данных
Урок про обратную сторону кэша: горячие ключи, лавину miss, падение Redis, cross-shard запросы и политики вытеснения, которые могут спасти или добить систему.
Теория:
Практика:
----------------------
Результат:
Теория:
- thundering herd и single flight как «склейка» одинаковых запросов;
- soft TTL, hard TTL, фоновые обновления и graceful cache fallback;
- negative cache: какие ошибки можно кэшировать, а какие опасно;
- cache avalanche, random TTL, jitter и proactive warmup;
- L1/L2 cache, горячие ключи и Redis sharding/hash slots;
- cross-DC и cross-shard latency, топологию Redis Cluster и локальность данных;
- noeviction, allkeys-lru, volatile-lru, allkeys-lfu, random, volatile-ttl и Redis-метрики.
Практика:
- реализуем single flight, jitter, multi-level cache и мониторинг hit / miss
----------------------
Результат:
- умеешь проектировать кэш-слой, который снижает нагрузку на источник, а не становится новым SPOF
Собираем наблюдаемость для диагностики и принятия решений: какие SLI выбрать, как связать SLO с бизнесом и какие алерты действительно будят инженера по делу
Теория:
Практика:
----------------------
Результат:
Теория:
- observability vs monitoring: метрики, логи, трейсы;
- SLI, SLO, SLA, error budget, burn rate и связь надежности с бизнес-операциями;
- Golden Signals, RED и USE для HTTP API / Go-сервисов / БД / Kafka / Redis и Kubernetes workload;
- Service Overview dashboard: RPS, 2xx / 4xx / 5xx, p50 / p95 / p99 latency, in-flight requests и dependency latency;
- Business SLO dashboard: успешные операции, failed operations, SLO compliance и error budget remaining;
- Kubernetes и Async dashboards: ready replicas, restarts, OOMKilled, rollout duration, Kafka lag, produce/consume rate и DLQ;
- runtime config dashboard: состояние feature flags из etcd, включенные деградации, время последнего изменения и влияние на SLO;
- хорошие и плохие алерты: actionable alerts, alert fatigue, runbook link и маршрутизация по владельцам.
Практика:
- собираем в Grafana все необходимые дашборды
- настраиваем HighErrorRate, HighLatency, ErrorBudgetBurn, NoReadyPods, RestartLoop, KafkaConsumerLagGrowing и DependencyLatencyHigh в Prometheus и Alertmanager
----------------------
Результат:
- можешь собрать минимальный production-grade набор дашбордов и алертов, которые помогают чинить инциденты
Практическая игра-симмуляция с упавшим продом. Система деградирует, алерты срабатывают. Мы — расследуем и принимаем решения
Теория:
Практика:
----------------------
Результат:
Теория:
- incident lifecycle: detect, triage, mitigate, rollback / degrade, close, postmortem;
- роли на инциденте: Incident Commander, Tech Lead, Scribe, Communications и владелец сервиса;
- severity levels, user impact, первые 5 минут, war room и правила коммуникации;
- safe delivery: canary, blue / green, feature flags на etcd, health-based rollout и rollback strategy;
- GameDay-сценарии: bad release, dependency degradation, Kafka lag incident и ошибка rollout capacity;
- инструменты: kubectl rollout status, kubectl rollout undo, kubectl describe, kubectl logs, k9s, stern, Grafana, Alertmanager и k6;
- runbook и blameless postmortem: timeline, root cause, what went well / wrong, action items и владельцы задач.
Практика:
- выкатываем плохую версию под нагрузкой
- ловим алерт
- анализируем дашборды
- включаем kill switch / degraded mode через etcd
- выбираем rollback / scale / cordon
- фиксируем timeline и собираем incident report + runbook
----------------------
Результат:
- проходишь полный цикл аварии: от первого алерта и оценки user impact до mitigation, rollback и postmortem
{
ффф"differences": {
ффффф"practice": true,
ффффф"theory": false
ффф}
}
ффф"differences": {
ффффф"practice": true,
ффффф"theory": false
ффф}
}
главное отличие этого курса от остальных
Практика с «рецептами» по решению типичных инцидентов в prod’e
Курс
Глубина изучения паттернов отказоустойчивости
«Микросервисы, как в BigTech» и курсы других школ
Основные паттерны с примерами кода. Изучается в середине курса и не так глубоко, как здесь. Упор на построение микросервисов с нуля
«System Design»
Изучается на уровне проектирования архитектуры без написания кода
из чего состоит курс
Последовательно смотрим каждую проблему в коде, разбираем ее в теории и сразу пишем решение
Уроки длятся по 1−1.5 часа и проходят два раза в неделю в свободное от работы время
Онлайн-уроки
Фидбек дает только преподаватель — никаких кураторов и помощников. Уточняющие вопросы можно задавать на еженедельных online-встречах
Q&A-сеccии и проверка ДЗ
Посмеяться, обсудить проблему или задать вопрос по паттернам отказоустойчивости архитектуры — на связи преподаватель и другие ученики курса
Общий чат
Книги, статьи, видео — отдадим все, что можно почитать на досуге и прокачаться еще сильнее
Дополнительные материалы
Выдадим после курса для подтверждения твоих навыков
Сертификат
преподает даниил булыкин, senior в ozon tech
распил монолита и построение многокомпонентного отказоустойчивого сервиса «Ozon Job»
Ozon Tech
разработка платформы DBass
ВКонтакте
max. нагрузка спроектированных систем
10 000 RPS
коммерческого опыта в BigTech
3000+ часов
в разработке высоконагруженных систем
4 года
{
ффф"reviews": {
ффффф"reliability": true
ффф}
}
ффф"reviews": {
ффффф"reliability": true
ффф}
}
отзывы студентов прошлого потока
В этом потоке исправили проблему с длительностью уроков
Вместо 6 длинных стало 12 коротких — до 90 минут
еще больше отзывов
- Семён КилановКурс был очень полезен — узнал много тонкостей о которых не знал ранее
- Ольга ЛаринаОчень много материала, подробные объяснения, много случаев из реальной практики
- Artem TretiakovКлассно, что разбирали реальные кейсы и реальные способы для применения в prod
- СергейДанил отвечает в личных сообщениях очень развернуто, если появляются вопросы
- Борис ПолошковКрутые ДЗ, имитирующие реальные бизнес-проблемы, глубина раскрытия тем
- Сергей ФастуновНасыщенность материала. Готовность ведущего к работе до «последнего клиента»
NPS = % Продвиженцев - % Недоброжелателей
где продвиженцы — оценка 9-10, неайтралы — оценка 7-8, недоброжелатели — оценка 0-6
NPS >75% — самый высокий показатель лояльности аудитории. В 2025 году даже NPS Apple равен примерно 61%
NPS >75% — самый высокий показатель лояльности аудитории. В 2025 году даже NPS Apple равен примерно 61%
CSI = сумма всех оценок / количество всех оценок
начинаем 27 октября
Можно оплатить в рассрочку и иностранной валютой. Вернем 100% средств в первую неделю обучения, если не понравится
12 online-занятий
Домашние задания
Q&A-сессии с ответами на вопросы
Общий чат и допматериалы
Доступ к урокам на 1 год
Проверка ДЗ от преподавателя
Вернем все деньги в первую неделю обучения, если не понравится
54 700 Р
53 900
Стоимость увеличится через:
52д 48ч 32м 17с
Можно в рассрочку — частями и без процентов
9 100
Р х 6
или
18 250
Р х 3
Будет дешевле, если проходили у нас:
При заполнении формы оплаты укажи email, к которому привязан аккаунт на платформе. Скидка применится автоматически
1 курс
54 700
49 230 Р
3+ курса
54 700
43 760 Р
5+ курсов
54 700
38 290 Р
12 online-занятий
Домашние задания
Q&A-сессии с ответами на вопросы
Общий чат и допматериалы
Доступ к урокам на 2 года
Проверка ДЗ от преподавателя
Вернем все деньги в первую неделю обучения, если не понравится
58 200 Р
66 400
Стоимость увеличится через:
52д 48ч 32м 17с
Можно в рассрочку — частями и без процентов
9 700
Р х 6
или
19 400
Р х 3
Будет дешевле, если проходили у нас:
При заполнении формы оплаты укажи email, к которому привязан аккаунт на платформе. Скидка применится автоматически
1 курс
58 200
52 380 Р
3+ курса
58 200
46 560 Р
5+ курсов
58 200
40 740 Р
Стандарт
12 online-занятий
Домашние задания
Q&A-сессии с ответами на вопросы
Общий чат и допматериалы
Доступ к урокам на 1 год
Проверка ДЗ от преподавателя
54 700 Р
53 900
Стоимость увеличится через:
52д 48ч 32м 17с
Можно в рассрочку — частями и без процентов
9100
х 6
|
18 250
х 3
Будет дешевле, если проходили у нас:
При заполнении формы оплаты укажи email, к которому привязан аккаунт на платформе. Скидка применится автоматически
1 курс
54 700
49 230 Р
3+ курса
54 700
43 760 Р
5+ курсов
54 700
38 290 Р
Премиум
12 online-занятий
Домашние задания
Q&A-сессии с ответами на вопросы
Общий чат и допматериалы
Доступ к урокам на 2 года
Проверка ДЗ от преподавателя
58 200 Р
66 400
Стоимость увеличится через:
52д 48ч 32м 17с
Можно в рассрочку — частями и без процентов
9100
х 6
|
18 250
х 3
Будет дешевле, если проходили у нас:
При заполнении формы оплаты укажи email, к которому привязан аккаунт на платформе. Скидка применится автоматически
1 курс
58 200
52 380 Р
3+ курса
58 200
46 560 Р
5+ курсов
58 200
40 740 Р
Оставьте заявку — свяжемся в течение суток, ответим на вопросы и оформим все документы
При таком способе стоимость курса увеличивается на 10% от текущей. Это связано с юридическими издержками на подготовку сделки
Оставить заявку на оплату
Подробнее о корпоративном обучении
Как согласовать обучение с работодателем
При таком способе стоимость курса увеличивается на 10% от текущей. Это связано с юридическими издержками на подготовку сделки
Оставить заявку на оплату
Подробнее о корпоративном обучении
Как согласовать обучение с работодателем
Частые вопросы
В индивидуальной проверке домашних работ. Но важно понимать: тариф без проверки не значит отсутствие фидбека или менее внимательное отношение к тебе
Все ученики в равных условиях и находятся в одном чате. Никаких разделений. Просто ученики премиум-тарифа получают персональный фидбек от преподавателя — и в этом вся разница
Студенты без проверки не остаются без обратной связи — если появляется вопрос по ДЗ, можно разобрать его на еженедельных Q&A-сессиях с преподавателем. А еще есть доступ к проверенным домашкам учеников с опцией персонального фидбека — можно изучать их работы, смотреть комментарии преподавателя и учиться на чужих ошибках
Тариф «Стандарт» — это не «урезанный» вариант, а нормальный рабочий формат. И в нем тоже есть обратная связь, просто точечная — в моменты, когда она действительно тебе нужна
Все ученики в равных условиях и находятся в одном чате. Никаких разделений. Просто ученики премиум-тарифа получают персональный фидбек от преподавателя — и в этом вся разница
Студенты без проверки не остаются без обратной связи — если появляется вопрос по ДЗ, можно разобрать его на еженедельных Q&A-сессиях с преподавателем. А еще есть доступ к проверенным домашкам учеников с опцией персонального фидбека — можно изучать их работы, смотреть комментарии преподавателя и учиться на чужих ошибках
Тариф «Стандарт» — это не «урезанный» вариант, а нормальный рабочий формат. И в нем тоже есть обратная связь, просто точечная — в моменты, когда она действительно тебе нужна
В любой IT-компании без исключения либо отказывает какой-то микросервис, либо падает вся система. Даже в BigTech
В командах с десятками или сотнями разработчиков каждый имеет свой уровень, и каждый допускает ошибки в коде. Любой инцидент начинается с этого. Рано или поздно он происходит, и с этим сталкивается любой Middle или Senior. Вопрос только в том, когда именно это случится
Даже если ты только начинаешь писать на Go, и тебя эта проблема не коснулась — с ростом грейда и ответственности ты с этим столкнешься. И блок-фактор твоего роста — умение строить отказоустойчивые системы и «тушить пожары» без помощи старших коллег.
Когда ты самостоятелен(-на), к тебе больше доверия, тебя сильнее ценят, и тебя готовы повышать. Особенно, когда один и тот же сервис постоянно падает, а ты наконец-то починил(-а) его раз и навсегда
В командах с десятками или сотнями разработчиков каждый имеет свой уровень, и каждый допускает ошибки в коде. Любой инцидент начинается с этого. Рано или поздно он происходит, и с этим сталкивается любой Middle или Senior. Вопрос только в том, когда именно это случится
Даже если ты только начинаешь писать на Go, и тебя эта проблема не коснулась — с ростом грейда и ответственности ты с этим столкнешься. И блок-фактор твоего роста — умение строить отказоустойчивые системы и «тушить пожары» без помощи старших коллег.
Когда ты самостоятелен(-на), к тебе больше доверия, тебя сильнее ценят, и тебя готовы повышать. Особенно, когда один и тот же сервис постоянно падает, а ты наконец-то починил(-а) его раз и навсегда
В неделю понадобится ≈8 часов:
Но часы обучения можно подстроить под себя — у тебя останутся записи уроков и Q&A-сессий с разбором вопросов по лекциям и практике. Если в них не получится найти нужные ответы, можно задать вопрос в общем чате с преподавателем
- два урока по 1−1.5 часа
- домашние задания — примерно 2 часа
Но часы обучения можно подстроить под себя — у тебя останутся записи уроков и Q&A-сессий с разбором вопросов по лекциям и практике. Если в них не получится найти нужные ответы, можно задать вопрос в общем чате с преподавателем
Основные требования для успешного прохождения курса по построению отказоустойчивой системы — знание Go и наличие базовых навыков работы с Kafka и Redis. Обучение рассчитано на golang-разработчиков уровня middle/senior.
Также подойдет для Junior — будет сложно, но полезно. Подойдет, если хочется быстрее расти и не пугает, что для усвоения материала придется дополнительно поизучать какие-то темы
Также подойдет для Junior — будет сложно, но полезно. Подойдет, если хочется быстрее расти и не пугает, что для усвоения материала придется дополнительно поизучать какие-то темы
Обучение оплачивается на сайте через платежный виджет GetCourse. Чек об оплате высылать не нужно, доступ в личный кабинет ученика приходит сразу после оплаты
Мы находимся в процессе получения государственной лицензии, поэтому пока нельзя получить налоговый вычет. Зато можно получить кешбэк на образовательные услуги, если он подключен у тебя в банке
Да, в платежном модуле есть несколько способов оплаты из за рубежа — можно выбрать подходящий
Да, у нас есть возможность произвести оплату обучения через юридическое лицо.
Чтобы сделать это, пожалуйста, свяжитесь с нами через форму заявки. Отвечаем в течение 1-го дня
Оставить заявку на оплату курса от лица компании
Чтобы сделать это, пожалуйста, свяжитесь с нами через форму заявки. Отвечаем в течение 1-го дня
Оставить заявку на оплату курса от лица компании
Да, ты сможешь вернуть всю стоимость курса в течение первой недели обучения, если останешься недоволен качеством или поймешь, что обучение тебе не подходит
Примерно 50
Не проблема — можешь сдать позже.
Вопросы по ДЗ можно задавать на еженедельных online-встречах или в чате — преподаватель или сокурсники во всем помогут
Вопросы по ДЗ можно задавать на еженедельных online-встречах или в чате — преподаватель или сокурсники во всем помогут
Да, все занятия ведет только один преподаватель. Он же проводит Q&A-сессии и отвечает на вопросы в общем чате.
У нас нет кураторов и помощников — только прямое общение студентов с преподавателем
У нас нет кураторов и помощников — только прямое общение студентов с преподавателем
задать вопрос
Пиши, если есть вопрос по курсу или не знаешь, с чего начать — поможем советом