Как учиться сложным вещам: система, где знания проверяются действием, а не перечитыванием

Можно знать, что такое spaced repetition, держать пять приложений для заметок и купить три курса — а через месяц не суметь с нуля объяснить, как работает NetworkPolicy. Сколько техник обучения ни знай, хорошее владение ими не означает, что ты умеешь учиться. В 2023 году я собрал брошюру больше чем на сто страниц: память, внимание, нейропластичность, интервальные повторения, мнемотехники, скорочтение, Pomodoro, мотивация. Пока продолжал преподавать, готовиться к сертификациям, учить языки и осваивать новые security-технологии, пришёл к неудобному выводу — и переписал подход.

Вот как я учусь сейчас. Способ рабочий не только для IT и безопасности: тем же циклом я подтягиваю английский, читаю технические книги и захожу в новые области вроде AppSec и DevSecOps.

Цель — глагол, а не название темы

Самая полезная привычка: формулировать цель действием, которое можно проверить.

Слабо: «выучить API Security», «подтянуть английский», «разобраться с AWS», «посмотреть курс по DevSecOps».

Проверяемо: найти Broken Object Level Authorization в тестовом API и показать exploit path с remediation; за 10 минут рассказать на английском о своём проекте и ответить на follow-up questions; построить threat model небольшого сервиса; добавить SAST и SCA в pipeline, намеренно сломать gate, понять причину и настроить policy; прочитать главу и через день восстановить её идеи без книги.

Это совпадает с тем, как профессиональные cybersecurity-фреймворки описывают работу — через tasks, knowledge and skills, а не через абстрактное «знаком с безопасностью». Для себя я зову такой подход performance-first learning.

Если цель нельзя проверить, обучение незаметно превращается в потребление контента: слайд открыт — понятно, слайд убрал — не помню.

Сначала карта, потом детали

Открыть книгу на Chapter 1 и дисциплинированно дойти до Chapter 27 выглядит правильно. Иногда так и надо. При ограниченном времени это обычно плохая точка входа. Сначала я хочу увидеть карту.

• Книга — оглавление, введение, summary, заголовки, ключевые термины.
• Технология — architecture overview, glossary, quick start, типичный workflow.
• Security — assets, trust boundaries, attack surface, identities, data flows, controls, telemetry.
• Английский — не «все времена английского», а ситуации: meeting, email, interview, объяснение finding, disagreement, clarification.

Принцип 80/20 для меня работает как вопрос, а не как закон: какие несколько понятий дадут возможность понимать остальные? Прежде чем читать сто страниц про OAuth/OIDC, полезно разобраться с участниками протокола, токенами, redirect flow и trust relationships. После этого детали перестают быть набором терминов и цепляются за готовый скелет.

Один хороший пример — и разбор его своими словами

В IT любят совет «не читай — просто делай». В нём есть правда, но в совсем новой области он часто превращается в два часа хаотичного тыканья и копирования команд из Stack Overflow без понимания, почему что-то заработало.

Для нового типа задач порядок у меня такой: посмотреть один качественный решённый пример; на каждом существенном шаге спросить, почему автор сделал именно это; закрыть пример; повторить самостоятельно; потом изменить условия задачи. Исследования worked examples и self-explanation показывают, что на раннем этапе освоения сложных когнитивных навыков это может быть эффективнее, чем сразу бросать новичка в полностью самостоятельный problem solving.

В безопасности это ложится идеально. Разбирая SSRF, я не просто смотрю готовый exploit, а проговариваю: почему этот input controllable; почему backend делает server-side request; какая trust boundary пересекается; что доступно из internal network; как отличить реальный SSRF от красивого payload, который ничего не даёт; какой control устранит root cause, а какой лишь усложнит эксплуатацию. В этот момент чужой walkthrough становится моей моделью.

Перечитывание врёт. Правду показывает извлечение

Схема, на которой я ловился годами: прочитал → понятно → перечитал → ещё понятнее → закрыл → ничего не помню. Знакомость материала легко спутать со знанием. Поэтому после небольшого блока я закрываю источник и пробую вытащить материал из памяти, не подглядывая.

После OAuth/OIDC — нарисовать flow с пустого листа. После Kubernetes — написать manifest без copy-paste. После видео по Burp Suite — повторить последовательность самому. После английского — сказать фразу вслух до того, как открыл карточку. После главы — записать 5–7 тезисов по памяти.

Retrieval practice хорошо поддерживается исследованиями обучения, но мне важнее другое: это диагностика. Не могу восстановить идею — проблема нашлась сейчас, а не на интервью и не в production.

После любой темы я задаю себе три вопроса. Первый — могу ли объяснить без источника (проверяет память). Второй — могу ли сделать без пошагового гайда (навык). Третий — узнаю ли эту же идею в другом контексте (transfer). Последний обычно самый неприятный.

Возвращаться полезнее, чем вбивать за один вечер

Распределённая практика работает, а универсального идеального расписания для любого человека и материала нет. Магию вокруг конкретных цифр кривой Эббингауза я убрал. Для новой темы стартую примерно так:

Это не календарь праздников. Вспоминаю легко — увеличиваю интервал. Всё развалилось — возвращаюсь раньше. Для языка удобно отдать повторения Anki или другой SRS. Для технических навыков карточки нужны далеко не всегда. Иногда лучший spaced repetition для AppSec — через неделю получить другую уязвимую API и снова пройти путь identify → exploit → impact → remediation → retest.

Цикл для безопасности: увидел → сломал → починил → объяснил

Общие советы про обучение здесь заканчиваются, и начинается специфика. Cybersecurity плохо учится только чтением: обзоры университетских курсов показывают устойчивый акцент на active learning, case studies, simulations, virtual labs и project-based assessment, а NIST NICE Framework описывает развитие специалиста через реальные work roles, tasks, knowledge и skills.

На практике я превращаю тему в цикл: Observe → Reproduce → Break/Attack → Fix/Mitigate → Retest → Explain the risk.

Pentest

Если тема — IDOR/BOLA, определения из OWASP мало. Хочу увидеть нормальный request, понять authorization context, изменить identifier, воспроизвести unauthorized access, доказать impact, предложить server-side control и проверить fix другим tenant. Тогда уязвимость перестаёт быть карточкой с термином.

AppSec

Для каждого класса проблем собираю mental template: asset → entry point → trust boundary → preconditions → abuse path → business impact → control → validation. После десятка разборов узнаёшь структуру проблемы раньше, чем вспомнишь номер CWE.

DevSecOps

Лаборатория обязательна. Не «посмотрел, как работает SAST», а: добавил scanner в pipeline; положил заведомую проблему; увидел finding; настроил gate; поймал false positive; сделал exception с понятным сроком и owner; проверил, что pipeline не превратился в генератор ненависти разработчиков к безопасности. Последний пункт часто важнее первых шести.

Английский — не предмет, а сценарии

С языком особенно легко коллекционировать знания вместо навыка. Можно знать Present Perfect, иметь 8000 карточек и зависнуть, когда на митинге спрашивают: What exactly is blocking the release? Поэтому подход сценарный. Не учу слово в отрыве, если могу выучить рабочий chunk: clarify — Could you clarify what you mean by ...?; concern — My main concern is ...; blocked — I'm currently blocked by ...; recommend — I'd recommend validating this before release. Речь собирается из таких блоков быстрее, чем из отдельных слов.

Что стоит сделать на этой неделе, чтобы система заработала:

• переписать одну свою учебную цель в проверяемое действие с результатом;
• перед следующим курсом или книгой потратить 20 минут на карту темы;
• после следующего блока закрыть источник и записать 5 тезисов по памяти;
• прогнать три вопроса: объяснить, сделать, узнать в новом контексте;
• поставить в календарь одно возвращение к материалу через неделю.

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