{:permitted_use_established=>
Такой строчкой нас встречает официальный документ из Росреестра, заверенный ЭЦП.
И как будто бы к тому, что у главных порталов страны, гос.банков и других жизненно важных ресурсов отваливается SSL-сертификат, делая соединение уязвимым, мы привыкли (я до сих пор нет, но уже не удивляюсь), но когда видишь ошибки такого уровня, то просто впадаешь в ступор.
В чем сложность покрыть формирование PDF-файла юнит-тестами? Форма стандартная, поля фиксированные. Полагаю, что изменение структуры случается крайне редко, но даже если нет, то добавить/удалить юниты ничего не стоит.
Вероятно, что-то даже покрыто тестами, но вдруг изменилась XML-схема и пресловутый парсер или модуль, отвечающий за формирование PDF, поломались.
Вывод один: пишите тесты, увеличивайте code coverage. Поверьте, лучше написать тесты, а потом удалить, чем так и не написать.
Такой строчкой нас встречает официальный документ из Росреестра, заверенный ЭЦП.
И как будто бы к тому, что у главных порталов страны, гос.банков и других жизненно важных ресурсов отваливается SSL-сертификат, делая соединение уязвимым, мы привыкли (я до сих пор нет, но уже не удивляюсь), но когда видишь ошибки такого уровня, то просто впадаешь в ступор.
В чем сложность покрыть формирование PDF-файла юнит-тестами? Форма стандартная, поля фиксированные. Полагаю, что изменение структуры случается крайне редко, но даже если нет, то добавить/удалить юниты ничего не стоит.
Вероятно, что-то даже покрыто тестами, но вдруг изменилась XML-схема и пресловутый парсер или модуль, отвечающий за формирование PDF, поломались.
Вывод один: пишите тесты, увеличивайте code coverage. Поверьте, лучше написать тесты, а потом удалить, чем так и не написать.
💯3✍1👍1
Не шутите с индексами, не верьте гарантиям и пишите надежный код
Работа с индексами массива сопряжена со множеством проблем. Тут и классическое "IndexOutOfRange", и, конечно же, получение неверного элемента из запрашиваемой позиции.
Возьмем простой код на Go. Нужно реализовать функцию getTag, которая ожидает в качестве аргумента массив и возвращает тэг нашей фичи. У нас также есть информация о том, что этот тип аргумента - "неизменный" легаси и у нас всегда приходит массив ровно с одним элементом. Разве может что-то плохое случиться, если получать значение прямо по индексу? Это выглядит быстро и удобно.
Абстрактный Петя так и решил, подготовил пул-реквест, отправил на код-ревью. Коллеги-синьоры, конечно, одобрили, так как все выглядело логично и лаконично.
Завязываться на конкретный индекс плохо, это знают все. Но, чтобы развеять сомнения, Петя даже прогнал свое решение через LLM, которая посоветовала избавиться от "магических" строк, добавить логирование, комментарии и тесты к коду, но в остальном все казалось хорошо.
Наполнившись уверенностью и добавив тестов с мыслью что легаси код надежен как швейцарский нож, Петя сделал "мердж" и выкатил на прод.
Прошел год. Петина фича работала как часы, пока вдруг неожиданно метрики здоровья не побежали вниз. Пользователи жалуются, что фича пропала, в команду приносят баг, а инцидент менеджер приглашает всех на встречу для разбора ситуации.
Оказалось, что в код попало то, чего не должно там быть в принципе. Гарантия, что массив состоит из одного значения, была нарушена, соседняя команда решила добавить еще одно значение ("json"), очевидно, не слышав ни про какие договоренности. Это же массив, почему бы его так и не использовать?
* * *
Вывод был сделан, хотфикс тоже. Теперь мы безопасно проходим по всему массиву и нам нестрашно, даже если он будет пустым. Ситуация нормализовалась, но Петин мир пошатнулся. Он понял, что любые гарантии условны. А если код хрупкий, то пенять на то, что кто-то не соблюдал договоренности будет глупо, ведь тебя все равно могут сделать крайним.
Герои вымешлены, все совпадения случайны :)
Существует правило: если человек может ошибиться, то он это сделает рано или поздно, он или его коллега. Поэтому очень важно исключать любые возможности для этого.
1. Забудьте про явную завязку на любые индексы, используйте безопасные конструкции (например, итерация по значениям массива). Заворачивайте коллекции в обертки с безопасным доступом к значениям и т.д.
2. Не верьте договоренностям, особенно словесным. Верьте написанному коду и тому, что может произойти в нем, исходя из общей логики и передаваемых аргументов (если код ответственный, то используйте фаззинг).
3. Лучше надежный и читаемый код, чем хрупкий, но сверхоптимизированный.
4. Помните, что код пишут люди, а им свойственно ошибаться.
Работа с индексами массива сопряжена со множеством проблем. Тут и классическое "IndexOutOfRange", и, конечно же, получение неверного элемента из запрашиваемой позиции.
Возьмем простой код на Go. Нужно реализовать функцию getTag, которая ожидает в качестве аргумента массив и возвращает тэг нашей фичи. У нас также есть информация о том, что этот тип аргумента - "неизменный" легаси и у нас всегда приходит массив ровно с одним элементом. Разве может что-то плохое случиться, если получать значение прямо по индексу? Это выглядит быстро и удобно.
Абстрактный Петя так и решил, подготовил пул-реквест, отправил на код-ревью. Коллеги-синьоры, конечно, одобрили, так как все выглядело логично и лаконично.
Завязываться на конкретный индекс плохо, это знают все. Но, чтобы развеять сомнения, Петя даже прогнал свое решение через LLM, которая посоветовала избавиться от "магических" строк, добавить логирование, комментарии и тесты к коду, но в остальном все казалось хорошо.
Наполнившись уверенностью и добавив тестов с мыслью что легаси код надежен как швейцарский нож, Петя сделал "мердж" и выкатил на прод.
package main
func main() {
tag := getTag([]string{"feature"})
if enableFeatureByTag(tag) {
print("OK")
return
}
print("FAILED")
}
func enableFeatureByTag(tag string) bool {
return tag == "feature"
}
func getTag(values []string) string {
if len(values) == 0 {
return ""
}
return values[0]
}
Прошел год. Петина фича работала как часы, пока вдруг неожиданно метрики здоровья не побежали вниз. Пользователи жалуются, что фича пропала, в команду приносят баг, а инцидент менеджер приглашает всех на встречу для разбора ситуации.
Оказалось, что в код попало то, чего не должно там быть в принципе. Гарантия, что массив состоит из одного значения, была нарушена, соседняя команда решила добавить еще одно значение ("json"), очевидно, не слышав ни про какие договоренности. Это же массив, почему бы его так и не использовать?
* * *
Вывод был сделан, хотфикс тоже. Теперь мы безопасно проходим по всему массиву и нам нестрашно, даже если он будет пустым. Ситуация нормализовалась, но Петин мир пошатнулся. Он понял, что любые гарантии условны. А если код хрупкий, то пенять на то, что кто-то не соблюдал договоренности будет глупо, ведь тебя все равно могут сделать крайним.
package main
func main() {
tag := getTag([]string{"json", "feature"})
if enableFeatureByTag(tag) {
print("OK")
return
}
print("FAILED")
}
func enableFeatureByTag(tag string) bool {
return tag == "feature"
}
func getTag(values []string) string {
for _, v := range values {
if v == "feature" {
return v
}
}
return ""
}
Герои вымешлены, все совпадения случайны :)
Существует правило: если человек может ошибиться, то он это сделает рано или поздно, он или его коллега. Поэтому очень важно исключать любые возможности для этого.
1. Забудьте про явную завязку на любые индексы, используйте безопасные конструкции (например, итерация по значениям массива). Заворачивайте коллекции в обертки с безопасным доступом к значениям и т.д.
2. Не верьте договоренностям, особенно словесным. Верьте написанному коду и тому, что может произойти в нем, исходя из общей логики и передаваемых аргументов (если код ответственный, то используйте фаззинг).
3. Лучше надежный и читаемый код, чем хрупкий, но сверхоптимизированный.
4. Помните, что код пишут люди, а им свойственно ошибаться.
🤔2
Как сделать продакшн среду стабильнее?
Одна из лучших (на мой взгляд) практик в биг техе - это проведение разбора инцидента после какого-либо происшествия на проде с привлечением всех причастных и заведением соответствующих артефактов.
В Авито это называется Live Site Review (LSR) и хорошо описано в playbook. Очевидно, идея не нова, а берет свое начало из лучших SRE практик.
Когда случается пожар, важно его потушить. Но еще важнее сделать так, чтобы в будущем он не повторился.
Подробно процесс описан по ссылке выше, я лишь хочу отметить основные этапы, когда о проблеме стало известно:
1. На инцидент заводится задача, которая затем станет основным артефактом о произошедшем.
2. Опустим подробности процесса починки, который сопряжен с большим количеством "веселья" (особенно, когда начинается цепочка с призывом ответственных в канал по решению проблемы). После исправления - фиксируем все, что может помочь в дальнейшем разборе, в задаче из п.1 (обязательно должна быть ссылка на тред(ы), где обсуждалась и решалась проблема).
3. Как правило, в больших компаниях есть человек, который фасилитирует данный процесс - инцидент-менеджер. Такой человек следит за всем: от появления первого сообщения о проблеме до момента, когда работы направленные на исправление первопричин произведены и все задокументировано. Одной из обязанностей менеджера является организация встречи со всеми причастными, где будут выясняться причины произошедшего и формироваться экшн-айтемы.
4. Итак, инцидент-менеджер создал встречу и пригласил всех. Теперь необходимо вместе пробежаться по чек-листу (как правило, задача из п.1 имеет унифицированный шаблон для разбора инцидентов), собрать фактуру и зафиксировать всю информацию. Для лучшего понимания предлагаю посмотреть "список типовых вопросов, которые стоит обсудить при разборе LSR".
5. Финальным аккордом должны стать экшн-айтемы с назначенными ответственными и обозначенными сроками выполнения. Очевидно, что такие задачи имеют приоритет при взятии в работу.
За 2 года в компании меня дважды приглашали на разбор инцидента, и это всегда очень интересно. По сути, вся встреча - это мозговой штурм с ответами на вопросы: "Можно ли быстрее было среагировать на проблему?", "Почему это допустили?", "Чего не хватило при тестировании?" и пр.
Удивительно, после LSR, когда о проблеме известно почти все, а обстоятельства очевидны, - видеть какая мелочь могла породить серьезный инцидент.
Часто это последовательность неудачного стечения обстоятельств. Как эффект бабочки или домино: один неосторожный if'чик или взятие элемента по индексу поломало отлично работающую фичу; метрики просели, но алерты не сработали, так как были некорректно настроены; дежурный не придал значение одному из многих упавших тестов синтетического мониторинга, так как после фича-фриза все немного штормило и случалось много ложных срабатываний; в конечном итоге оперативно пофикшенный баг не мог сутки доехать до прода из-за не работающей инфраструктуры… Продолжать такую цепочку можно до бесконечности, но нужно ли? :)
Запомнить: устанавливаем первопричину, вырабатываем экшн-айтемы для исправления хрупких мест, которые привели к инциденту, с назначением сроков и ответственных, документируем и фиксируем все артефакты.
Напишите в комментариях как в вашей компании организована практика по разбору инцидентов и насколько считаете такой процесс полезным ⤵️
Одна из лучших (на мой взгляд) практик в биг техе - это проведение разбора инцидента после какого-либо происшествия на проде с привлечением всех причастных и заведением соответствующих артефактов.
В Авито это называется Live Site Review (LSR) и хорошо описано в playbook. Очевидно, идея не нова, а берет свое начало из лучших SRE практик.
Когда случается пожар, важно его потушить. Но еще важнее сделать так, чтобы в будущем он не повторился.
Подробно процесс описан по ссылке выше, я лишь хочу отметить основные этапы, когда о проблеме стало известно:
1. На инцидент заводится задача, которая затем станет основным артефактом о произошедшем.
2. Опустим подробности процесса починки, который сопряжен с большим количеством "веселья" (особенно, когда начинается цепочка с призывом ответственных в канал по решению проблемы). После исправления - фиксируем все, что может помочь в дальнейшем разборе, в задаче из п.1 (обязательно должна быть ссылка на тред(ы), где обсуждалась и решалась проблема).
3. Как правило, в больших компаниях есть человек, который фасилитирует данный процесс - инцидент-менеджер. Такой человек следит за всем: от появления первого сообщения о проблеме до момента, когда работы направленные на исправление первопричин произведены и все задокументировано. Одной из обязанностей менеджера является организация встречи со всеми причастными, где будут выясняться причины произошедшего и формироваться экшн-айтемы.
4. Итак, инцидент-менеджер создал встречу и пригласил всех. Теперь необходимо вместе пробежаться по чек-листу (как правило, задача из п.1 имеет унифицированный шаблон для разбора инцидентов), собрать фактуру и зафиксировать всю информацию. Для лучшего понимания предлагаю посмотреть "список типовых вопросов, которые стоит обсудить при разборе LSR".
5. Финальным аккордом должны стать экшн-айтемы с назначенными ответственными и обозначенными сроками выполнения. Очевидно, что такие задачи имеют приоритет при взятии в работу.
За 2 года в компании меня дважды приглашали на разбор инцидента, и это всегда очень интересно. По сути, вся встреча - это мозговой штурм с ответами на вопросы: "Можно ли быстрее было среагировать на проблему?", "Почему это допустили?", "Чего не хватило при тестировании?" и пр.
Удивительно, после LSR, когда о проблеме известно почти все, а обстоятельства очевидны, - видеть какая мелочь могла породить серьезный инцидент.
Часто это последовательность неудачного стечения обстоятельств. Как эффект бабочки или домино: один неосторожный if'чик или взятие элемента по индексу поломало отлично работающую фичу; метрики просели, но алерты не сработали, так как были некорректно настроены; дежурный не придал значение одному из многих упавших тестов синтетического мониторинга, так как после фича-фриза все немного штормило и случалось много ложных срабатываний; в конечном итоге оперативно пофикшенный баг не мог сутки доехать до прода из-за не работающей инфраструктуры… Продолжать такую цепочку можно до бесконечности, но нужно ли? :)
Запомнить: устанавливаем первопричину, вырабатываем экшн-айтемы для исправления хрупких мест, которые привели к инциденту, с назначением сроков и ответственных, документируем и фиксируем все артефакты.
Напишите в комментариях как в вашей компании организована практика по разбору инцидентов и насколько считаете такой процесс полезным ⤵️
👍1
Май 2024:
📌 Вероятно, один из самых плотных и насыщенных месяцев за последние несколько лет. Май выдался очень сложным: тут и личные дела сыграли, и невероятно интенсивные продуктовые задачи, требующие максимального включения. Большинство моих коммитов (за исключением онбординга - тут все штатно) пошло под откос.
⚡ Главное, чтобы черные лебеди не выбивали вас из колеи. Взбодрились, наладили расписание и пошли дальше.
навыки
✔️ Завершил курс Быстрая прокачка в ООП (Object Calisthenics - очень интересная штука, хочется порефлексировать в отдельном посте).
✔️ Рассмотрел простые правила проектного дизайна.
✔️ Потренировался в приведении своего очень старого кода в соответствие с SRP: раз, два, три.
карьера
✔️ Взял стратегический фокус на повышение экспертизы в области дизайна систем (уже скоро расскажу подробнее как туда двигаюсь), так как все больше появляется запросов в рабочих задачах на проектирование архитектуры.
прочее
✔️ В какой-то момент у меня отвалилась фича по генерации изображений у шахматного бота, который публикует задачки в рабочий канал. Пришлось фиксить ASAP и выпускать версию v1.0.6, так как 3 раза в неделю коллеги ожидают очередную задачку :)
✔️ Ввел в свои привычки ранний подъем и спорт - эти ребята хорошо помогают оставаться эффективным целый день.
#результаты
📌 Вероятно, один из самых плотных и насыщенных месяцев за последние несколько лет. Май выдался очень сложным: тут и личные дела сыграли, и невероятно интенсивные продуктовые задачи, требующие максимального включения. Большинство моих коммитов (за исключением онбординга - тут все штатно) пошло под откос.
⚡ Главное, чтобы черные лебеди не выбивали вас из колеи. Взбодрились, наладили расписание и пошли дальше.
навыки
✔️ Завершил курс Быстрая прокачка в ООП (Object Calisthenics - очень интересная штука, хочется порефлексировать в отдельном посте).
✔️ Рассмотрел простые правила проектного дизайна.
✔️ Потренировался в приведении своего очень старого кода в соответствие с SRP: раз, два, три.
карьера
✔️ Взял стратегический фокус на повышение экспертизы в области дизайна систем (уже скоро расскажу подробнее как туда двигаюсь), так как все больше появляется запросов в рабочих задачах на проектирование архитектуры.
прочее
✔️ В какой-то момент у меня отвалилась фича по генерации изображений у шахматного бота, который публикует задачки в рабочий канал. Пришлось фиксить ASAP и выпускать версию v1.0.6, так как 3 раза в неделю коллеги ожидают очередную задачку :)
✔️ Ввел в свои привычки ранний подъем и спорт - эти ребята хорошо помогают оставаться эффективным целый день.
#результаты
👍3🔥3
Новиков > путь в Big Tech
В ближайшие месяцы планирую взять на себя роль Security Champion нашей продуктовой команды. Это поможет улучшить свои знания в кибер-безопасности, а также усилить свою команду экспертизой в этом направлении. Если совсем кратко, то секьюрити чемпион предупреждает…
Моделирование угроз
В начале недели перенял роль SC. Теперь являюсь амбассадором безопасности в нашей фича команде.
Перед разработкой новой функциональности или сервиса не будет лишним организовать сессию по моделированию угроз, на которой вы с командой сможете почелленджить свою систему на наличие уязвимостей и потенциально незащищенных мест.
Основные этапы
1️⃣ Перед моделированием угроз сперва необходимо декомпозировать фичу, нарисовать верхнеуровневую архитектуру, описать как будут использоваться, перемещаться, обрабатываться и храниться данные в системе. Это поможет впоследствии определить узкие места и сразу обозначить возможные пути решения (необходимо будет учесть при разработке).
2️⃣ Теперь важно найти опасные угрозы. Пробуем ответить на вопрос: "Что может пойти не так?". Здесь могут работать подходы:
a) Берем библиотеку атак (крупные компании обычно организуют свою основанную на опыте), но для начала можно начать с тех, которые обозначил OWASP, и задаемся вопросами о возможных последствиях для нашей системы и ее пользователях при попытке осуществления каждой из атак.
b) Используем методику STRIDE, которую активно применяет у себя Microsoft. Такой подход подразделяет угрозы на 6 основных категорий (спуфинг, незаконное изменение, отказ в обслуживании и другие). С данной моделью работаем также, как и с библиотекой атак, задавая, например, такой вопрос применительно к незаконному изменению: "Как злоумышленник может изменить наши данные или повлиять на них?"
3️⃣ Когда угрозы обозначены, приоритизируем их:
a) Учесть сразу - решаем как обработать, заводим задачу и выполняем вместе с разрабатываемой фичой
b) Отложить на будущее - заводим задачу и кладем в бэклог (можно закрывать в рамках тех. долга)
c) Принимаем риск - если вероятность возникновения минимальная, а трудоемкость закрытия уязвимости существенная, то фиксируем данный момент в задаче или документации (если такой риск все-таки случится, то останутся артефакты о том, что мы сознательно пошли на такое решение)
4️⃣ На заключительном этапе остается только проверифицировать, что все, что мы нашли выше, учтено в нашей системе/фиче перед деплоем. Здесь подходят: автоматические тесты, сканнеры уязвимостей, код-ревью, тесты на проникновения и др. Без финальной проверки того, что мы учли в системе все, что описали до, вся наша работа будет напрасна, так как можно найти сколь угодно много угроз, но ничего в результате не сделать.
Самые полезные материалы, чтобы провести моделирование угроз правильно:
- Шпаргалка от OWASP
- Интерактианый курс от Microsoft и его подмодуль, который позволяет за 15 минут познакомиться с темой.
Если у вас мало времени, но в вопросе разобраться хочется, то предлагаю прочитать отличную статью от эксперта по информационной безопасности.
В начале недели перенял роль SC. Теперь являюсь амбассадором безопасности в нашей фича команде.
Перед разработкой новой функциональности или сервиса не будет лишним организовать сессию по моделированию угроз, на которой вы с командой сможете почелленджить свою систему на наличие уязвимостей и потенциально незащищенных мест.
Основные этапы
1️⃣ Перед моделированием угроз сперва необходимо декомпозировать фичу, нарисовать верхнеуровневую архитектуру, описать как будут использоваться, перемещаться, обрабатываться и храниться данные в системе. Это поможет впоследствии определить узкие места и сразу обозначить возможные пути решения (необходимо будет учесть при разработке).
2️⃣ Теперь важно найти опасные угрозы. Пробуем ответить на вопрос: "Что может пойти не так?". Здесь могут работать подходы:
a) Берем библиотеку атак (крупные компании обычно организуют свою основанную на опыте), но для начала можно начать с тех, которые обозначил OWASP, и задаемся вопросами о возможных последствиях для нашей системы и ее пользователях при попытке осуществления каждой из атак.
b) Используем методику STRIDE, которую активно применяет у себя Microsoft. Такой подход подразделяет угрозы на 6 основных категорий (спуфинг, незаконное изменение, отказ в обслуживании и другие). С данной моделью работаем также, как и с библиотекой атак, задавая, например, такой вопрос применительно к незаконному изменению: "Как злоумышленник может изменить наши данные или повлиять на них?"
3️⃣ Когда угрозы обозначены, приоритизируем их:
a) Учесть сразу - решаем как обработать, заводим задачу и выполняем вместе с разрабатываемой фичой
b) Отложить на будущее - заводим задачу и кладем в бэклог (можно закрывать в рамках тех. долга)
c) Принимаем риск - если вероятность возникновения минимальная, а трудоемкость закрытия уязвимости существенная, то фиксируем данный момент в задаче или документации (если такой риск все-таки случится, то останутся артефакты о том, что мы сознательно пошли на такое решение)
4️⃣ На заключительном этапе остается только проверифицировать, что все, что мы нашли выше, учтено в нашей системе/фиче перед деплоем. Здесь подходят: автоматические тесты, сканнеры уязвимостей, код-ревью, тесты на проникновения и др. Без финальной проверки того, что мы учли в системе все, что описали до, вся наша работа будет напрасна, так как можно найти сколь угодно много угроз, но ничего в результате не сделать.
Самые полезные материалы, чтобы провести моделирование угроз правильно:
- Шпаргалка от OWASP
- Интерактианый курс от Microsoft и его подмодуль, который позволяет за 15 минут познакомиться с темой.
Если у вас мало времени, но в вопросе разобраться хочется, то предлагаю прочитать отличную статью от эксперта по информационной безопасности.
⚡2
Как научиться проектировать системы? И кому это нужно?
В начале июня обещал рассказать как повышаю экспертизу в проектировании систем. Но сперва лирическое отступление.
Ответьте себе: стоит ли туда идти прямо сейчас с текущим опытом? И с какой целью?
Если рассмотреть инженера в компании, где налажены процессы и есть понятное разделение ответственности, то умение проектировать системы ожидают от старших разработчиков ближе к уровню синьор.
Зачастую собеседования на такой грейд сопровождаются классическим system-design interview, где вас попросят спроектировать твиттер, ютуб или другую популярную систему.
Конечно, не мало стартапов или гос. компаний, где джуны занимаются проектированием сложной системы, но это нездоровая практика и мы не будем про нее говорить.
Важно понимать: одно дело научиться правильному проектному мышлению и совсем другое - проходить интервью.
В идеале, чтобы из первого следовало второе. Но бывает, что цель - пройти секцию по системному дизайну, тогда натаскивание через мок-собеседования, конечно, поможет преуспеть, но уверенный навык не выработает. Про подготовку к собеседованиям сказано очень много, поэтому мы в эту тему не идем.
Потребность в навыках system design на разных этапах:
1. Представим ситуацию, что человек имеет небольшой опыт (до 2-х лет) и занимает позицию junior/middle- разработчик. В таком случае (на мой взгляд) углубляться в проектирование может оказаться даже вредным, так как легко закопаться в обилии материала, потерять мотивацию и основной рабочий фокус.
2. Если же вы пришли из другой области в веб (как я когда-то), то будет полезным на верхнем уровне изучить как это все устроено, чтобы сложить общую картину. Лучше этой книжки, насколько я знаю, пока не придумали.
3. Итак, вы в разработке уверенных 2-3 года, четко обозначили себе цель (продвижение к синьорскому грейду) и хотите к ней как можно быстрее прийти. При этом вам важно выработать уверенный навык проектирования, а не просто пройти очередное интервью.
Так как первые пункты по своей сути тривиальны, то стоит внимательнее рассмотреть №3, о чем дальше и пойдет речь.
У меня в закладках давно живут:
- дизайн праймер
- дорожная карта
И еще немало крутого материала, который стараюсь время от времени почитывать 🤓
Если у вас отличная дисциплина и есть четкое понимание как выстроить учебный план, то самостоятельное обучение по материалам может сработать.
Но я сейчас решил подойти к вопросу комплексно, так как увидел потребность и немного устал лавировать по бесконечным материалам.
В моем фокусе сейчас оказалось 2 проекта:
- курс по анализу систем (АС)
- курс по объектно-ориентированному анализу и проектированию (ООАП)
Второй курс более прикладной и объектно-ориентированный, в ходе которого планирую написать консольную игру. Это больше пет-проект, так как обратной связи на нем нет.
Первый же ориентирован на работу с требованиями, анализа бизнеса, выбора подходящей архитектуры и пр. Есть эксперт для обратной связи и правильный подход к обучению.
⚡️ Уже сейчас крупным открытием из курса по АС для меня было узнать про воркшоп Event Storming. Поставил себе цель - провести его в своей команде. Это действительно захватывающий подход к проектированию, и я про него расскажу отдельно.
Так как же все-таки научиться проектировать системы, если решили, что хотите в этом разобраться?
Самый очевидный ответ - через практику. Хорошо, если есть возможность методом проб и ошибок делать это на работе, но такая роскошь не всегда доступна, а иногда и опасна, так как бизнес будет терять деньги, пока вы набиваете шишки.
Поэтому практика должна быть под чутким руководством более опытных коллег/менторов/преподавателей - они помогут не заплутать. Помните: во время обучения обратная связь - это все, без нее очень легко забуксовать. Хорошим вариантом может стать разбор архитектурных кат с наставником.
Начните проектировать. Собирайте обратную связь по своему дизайну. Снова проектируйте, улучшая первоначальное решение.
В конечном итоге, вы сделаете ощутимый скачок в своем развитии.
В начале июня обещал рассказать как повышаю экспертизу в проектировании систем. Но сперва лирическое отступление.
Ответьте себе: стоит ли туда идти прямо сейчас с текущим опытом? И с какой целью?
Если рассмотреть инженера в компании, где налажены процессы и есть понятное разделение ответственности, то умение проектировать системы ожидают от старших разработчиков ближе к уровню синьор.
Зачастую собеседования на такой грейд сопровождаются классическим system-design interview, где вас попросят спроектировать твиттер, ютуб или другую популярную систему.
Конечно, не мало стартапов или гос. компаний, где джуны занимаются проектированием сложной системы, но это нездоровая практика и мы не будем про нее говорить.
Важно понимать: одно дело научиться правильному проектному мышлению и совсем другое - проходить интервью.
В идеале, чтобы из первого следовало второе. Но бывает, что цель - пройти секцию по системному дизайну, тогда натаскивание через мок-собеседования, конечно, поможет преуспеть, но уверенный навык не выработает. Про подготовку к собеседованиям сказано очень много, поэтому мы в эту тему не идем.
Потребность в навыках system design на разных этапах:
1. Представим ситуацию, что человек имеет небольшой опыт (до 2-х лет) и занимает позицию junior/middle- разработчик. В таком случае (на мой взгляд) углубляться в проектирование может оказаться даже вредным, так как легко закопаться в обилии материала, потерять мотивацию и основной рабочий фокус.
2. Если же вы пришли из другой области в веб (как я когда-то), то будет полезным на верхнем уровне изучить как это все устроено, чтобы сложить общую картину. Лучше этой книжки, насколько я знаю, пока не придумали.
3. Итак, вы в разработке уверенных 2-3 года, четко обозначили себе цель (продвижение к синьорскому грейду) и хотите к ней как можно быстрее прийти. При этом вам важно выработать уверенный навык проектирования, а не просто пройти очередное интервью.
Так как первые пункты по своей сути тривиальны, то стоит внимательнее рассмотреть №3, о чем дальше и пойдет речь.
У меня в закладках давно живут:
- дизайн праймер
- дорожная карта
И еще немало крутого материала, который стараюсь время от времени почитывать 🤓
Если у вас отличная дисциплина и есть четкое понимание как выстроить учебный план, то самостоятельное обучение по материалам может сработать.
Но я сейчас решил подойти к вопросу комплексно, так как увидел потребность и немного устал лавировать по бесконечным материалам.
В моем фокусе сейчас оказалось 2 проекта:
- курс по анализу систем (АС)
- курс по объектно-ориентированному анализу и проектированию (ООАП)
Второй курс более прикладной и объектно-ориентированный, в ходе которого планирую написать консольную игру. Это больше пет-проект, так как обратной связи на нем нет.
Первый же ориентирован на работу с требованиями, анализа бизнеса, выбора подходящей архитектуры и пр. Есть эксперт для обратной связи и правильный подход к обучению.
⚡️ Уже сейчас крупным открытием из курса по АС для меня было узнать про воркшоп Event Storming. Поставил себе цель - провести его в своей команде. Это действительно захватывающий подход к проектированию, и я про него расскажу отдельно.
Так как же все-таки научиться проектировать системы, если решили, что хотите в этом разобраться?
Самый очевидный ответ - через практику. Хорошо, если есть возможность методом проб и ошибок делать это на работе, но такая роскошь не всегда доступна, а иногда и опасна, так как бизнес будет терять деньги, пока вы набиваете шишки.
Поэтому практика должна быть под чутким руководством более опытных коллег/менторов/преподавателей - они помогут не заплутать. Помните: во время обучения обратная связь - это все, без нее очень легко забуксовать. Хорошим вариантом может стать разбор архитектурных кат с наставником.
Начните проектировать. Собирайте обратную связь по своему дизайну. Снова проектируйте, улучшая первоначальное решение.
В конечном итоге, вы сделаете ощутимый скачок в своем развитии.
👍4🔥3⚡2
Секрет хорошего дизайна, о котором знают все гиганты в IT [1/2]
Рассмотрим упрощенную модель "зрелости" по реализации проектных решений разбитую на 5 уровней:
Уровень 1
- Пишем код
Уровень 2
- Пишем код -> Согласовываем
Уровень 3
- Согласовываем -> Пишем код
Уровень 4
- Согласовываем -> Пишем код -> Документируем решение
Уровень 5
- Документируем решение -> Согласовываем -> Пишем код
Первый уровень, когда важен только код и рабочий прототип, характерен для стартапов или студенческих проектов. Согласования не нужны, документация - тем более, так как все быстро меняется и просто нет на нее времени.
Начиная со второго, согласование решений обычно требуется с владельцами зависимых сервисов, продактом, тимлидом, дизайнером, юристами и т.д. Единственной разумной практикой является делать это до разработки, но бывает так, что "не знали", "забыли", "не подумали", что в конечном счете удлиняет процесс, так как любые согласования - всегда блокер на пути к релизу.
Важность актуальной документации сложно переоценить, поэтому, если разработчики уже работают на 4-м уровне зрелости, то это очень хороший знак.
В погоне за низким TTM часто 5-ый уровень может быть не достижим, так как требует доп. ресурса, и хорошие разработчики вынуждены лавировать между 3 и 4 в зависимости от капасити спринта.
"Документирование решений" и "Согласования" в совокупности образуют процесс под названием "Дизайн ревью" (Design Review), который стал стандартом для разработки любых решений в Биг Техе.
В эффективности этого процесса вопросов ни у кого нет, сейчас основная задача - сделать его как можно более быстрым без потери качества принимаемых решений. Читайте как Google улучшает этот процесс у себя.
Авито тоже не стоит на месте и постоянно оптимизирует свои процессы. Так в компании на смену дорогих архитектурных комитетов пришел Tech Design Review или просто TDR.
Как с ним работать, чтобы создавать надежные системы, поговорим во второй части.
Рассмотрим упрощенную модель "зрелости" по реализации проектных решений разбитую на 5 уровней:
Уровень 1
- Пишем код
Уровень 2
- Пишем код -> Согласовываем
Уровень 3
- Согласовываем -> Пишем код
Уровень 4
- Согласовываем -> Пишем код -> Документируем решение
Уровень 5
- Документируем решение -> Согласовываем -> Пишем код
Первый уровень, когда важен только код и рабочий прототип, характерен для стартапов или студенческих проектов. Согласования не нужны, документация - тем более, так как все быстро меняется и просто нет на нее времени.
Начиная со второго, согласование решений обычно требуется с владельцами зависимых сервисов, продактом, тимлидом, дизайнером, юристами и т.д. Единственной разумной практикой является делать это до разработки, но бывает так, что "не знали", "забыли", "не подумали", что в конечном счете удлиняет процесс, так как любые согласования - всегда блокер на пути к релизу.
Важность актуальной документации сложно переоценить, поэтому, если разработчики уже работают на 4-м уровне зрелости, то это очень хороший знак.
В погоне за низким TTM часто 5-ый уровень может быть не достижим, так как требует доп. ресурса, и хорошие разработчики вынуждены лавировать между 3 и 4 в зависимости от капасити спринта.
"Документирование решений" и "Согласования" в совокупности образуют процесс под названием "Дизайн ревью" (Design Review), который стал стандартом для разработки любых решений в Биг Техе.
В эффективности этого процесса вопросов ни у кого нет, сейчас основная задача - сделать его как можно более быстрым без потери качества принимаемых решений. Читайте как Google улучшает этот процесс у себя.
Авито тоже не стоит на месте и постоянно оптимизирует свои процессы. Так в компании на смену дорогих архитектурных комитетов пришел Tech Design Review или просто TDR.
Как с ним работать, чтобы создавать надежные системы, поговорим во второй части.
🔥4👍1
Секрет хорошего дизайна, о котором знают все гиганты в IT [2/2]
Итак, Tech Design Review. Что за ним скрывается?
Процесс будет описан так, как это принято в Авито. В других компаниях он может отличаться, так как компании выстраивают внутренние процессы под себя, исходя из практического опыта. Полное описание процесса-TDR читайте в плейбуке.
Представьте, что сделали пул-реквест (или мердж-реквест) в сервис. Но вместо кода с новой фичей или багфиксом у вас документ, где описано решение какой-либо технической проблемы, которое затрагивает сразу несколько доменов и потенциально влияет на весь продукт и другие команды. Ревьюеры смотрят код, оставляют комментарии...
В TDR механика абсолютно такая же, а весь процесс состоит из следующих этапов:
0️⃣ Обозначаем проблему
TDR не возникает на пустом месте: существует проблема, которую важно решить. Формируем ее. Важно уделить данному этапу должное внимание, чтобы будущие ревьюеры документа поняли необходимость вашего решения.
1️⃣ Находим решение
Когда проблема обозначена, приступаем к решению. На этом этапе происходит основная исследовательская работа: рисуется верхнеуровневая архитектура с зависимостями, считается нагрузка на сервис, потребление ресурсов и прочее. Здесь уже все зависит от задачи, но по результату у вас должно получиться решение обязательно сопровождаемое артефактами, чтобы можно было бы наглядно погрузиться в контекст.
2️⃣ Собираем вместе
Настало время собрать все воедино. Удобно, когда есть специальный инструмент для этого, предоставляющий шаблон с основными полями. Но, если инструмента нет, то просто собираем по секциям то, что делали раньше:
проблема <=> описание решения <=> схема зависимостей <=> компромиссы <=> альтернативы <=> FAQ <=> нагрузка и расчеты <=> ресурсы <=> структура баз данных <=> метрики
Структура выше хорошо ложится на создание нового сервиса. Для прочих решений могут подойти другие шаблоны.
Фактически общая формула такая:
проблема -> решение -> обоснование
3️⃣ Отдаем в ревью
На этом этапе у нас есть оформленная версия документа (v1.0). Выбираем экспертов, в домене которых будет происходить новая разработка. Чтобы найти экспертов можно задать 2 вопроса: "Кто владелец сервиса, на которое будет оказано влияние?" и "Кому потенциально наше решение облегчит или затруднит жизнь?".
Эксперты выбраны. Отправляем на согласование и ждем.
4️⃣ Ревью
Собирается обратная связь от экспертов, автор документа отвечает на вопросы. На этом этапе эксперты должны поставить свою оценку (флаг):
🟢 - вопросов нет
🟡 - есть неблокирующие вопросы, можно начинать разработку
🔴 - такое решение нельзя запускать в прод
По результатам возможны ситуации: документ согласован, документ отправлен на доработку (фактически мы отправляемся к пункту 2 и прорабатываем возникшие вопросы, затем все повторяется) и документ отменен как невозможный к реализации с текущим решением или обоснованием.
5️⃣ Завершение
В зависимости от статуса на предыдущем шаге возможны варианты, но, если все хорошо, то можно постепенно планировать будущую разработку и приступать к реализации.
Важно отметить, что согласование TDR проводится полностью в асинхронном формате. Это быстро и удобно для всех. Конечно, при необходимости можно организовать встречу, чтобы решить спорные моменты, но это скорее исключение. С таким форматом согласен и Microsoft загляните к ним в плейбук, чтобы узнать подробнее.
Если будете углубляться в тему, то можете столкнуться с ADR (Architecture decision record) - это тоже важный документ, но представляет собой другой процесс и лучше мы рассмотрим его отдельно.
К слову, сейчас нахожусь на этапе ревью собственного TDR в компании. Уже есть интересные инсайты, которыми хочется поделиться.
Но это позже, а пока продолжаем работать.
Итак, Tech Design Review. Что за ним скрывается?
Процесс будет описан так, как это принято в Авито. В других компаниях он может отличаться, так как компании выстраивают внутренние процессы под себя, исходя из практического опыта. Полное описание процесса-TDR читайте в плейбуке.
Представьте, что сделали пул-реквест (или мердж-реквест) в сервис. Но вместо кода с новой фичей или багфиксом у вас документ, где описано решение какой-либо технической проблемы, которое затрагивает сразу несколько доменов и потенциально влияет на весь продукт и другие команды. Ревьюеры смотрят код, оставляют комментарии...
В TDR механика абсолютно такая же, а весь процесс состоит из следующих этапов:
0️⃣ Обозначаем проблему
TDR не возникает на пустом месте: существует проблема, которую важно решить. Формируем ее. Важно уделить данному этапу должное внимание, чтобы будущие ревьюеры документа поняли необходимость вашего решения.
1️⃣ Находим решение
Когда проблема обозначена, приступаем к решению. На этом этапе происходит основная исследовательская работа: рисуется верхнеуровневая архитектура с зависимостями, считается нагрузка на сервис, потребление ресурсов и прочее. Здесь уже все зависит от задачи, но по результату у вас должно получиться решение обязательно сопровождаемое артефактами, чтобы можно было бы наглядно погрузиться в контекст.
2️⃣ Собираем вместе
Настало время собрать все воедино. Удобно, когда есть специальный инструмент для этого, предоставляющий шаблон с основными полями. Но, если инструмента нет, то просто собираем по секциям то, что делали раньше:
проблема <=> описание решения <=> схема зависимостей <=> компромиссы <=> альтернативы <=> FAQ <=> нагрузка и расчеты <=> ресурсы <=> структура баз данных <=> метрики
Структура выше хорошо ложится на создание нового сервиса. Для прочих решений могут подойти другие шаблоны.
Фактически общая формула такая:
проблема -> решение -> обоснование
3️⃣ Отдаем в ревью
На этом этапе у нас есть оформленная версия документа (v1.0). Выбираем экспертов, в домене которых будет происходить новая разработка. Чтобы найти экспертов можно задать 2 вопроса: "Кто владелец сервиса, на которое будет оказано влияние?" и "Кому потенциально наше решение облегчит или затруднит жизнь?".
Эксперты выбраны. Отправляем на согласование и ждем.
4️⃣ Ревью
Собирается обратная связь от экспертов, автор документа отвечает на вопросы. На этом этапе эксперты должны поставить свою оценку (флаг):
🟢 - вопросов нет
🟡 - есть неблокирующие вопросы, можно начинать разработку
🔴 - такое решение нельзя запускать в прод
По результатам возможны ситуации: документ согласован, документ отправлен на доработку (фактически мы отправляемся к пункту 2 и прорабатываем возникшие вопросы, затем все повторяется) и документ отменен как невозможный к реализации с текущим решением или обоснованием.
5️⃣ Завершение
В зависимости от статуса на предыдущем шаге возможны варианты, но, если все хорошо, то можно постепенно планировать будущую разработку и приступать к реализации.
Важно отметить, что согласование TDR проводится полностью в асинхронном формате. Это быстро и удобно для всех. Конечно, при необходимости можно организовать встречу, чтобы решить спорные моменты, но это скорее исключение. С таким форматом согласен и Microsoft загляните к ним в плейбук, чтобы узнать подробнее.
Если будете углубляться в тему, то можете столкнуться с ADR (Architecture decision record) - это тоже важный документ, но представляет собой другой процесс и лучше мы рассмотрим его отдельно.
К слову, сейчас нахожусь на этапе ревью собственного TDR в компании. Уже есть интересные инсайты, которыми хочется поделиться.
Но это позже, а пока продолжаем работать.
👍3
Июнь 2024:
навыки
✔️ Завершил больше половины курса по анализу систем, выполнил 4/5 всех заданий курса. Улучшил экспертизу в областях: работа с требованиями и внешними ограничениями, выделение основных частей системы при помощи Event Storming, выбор архитектурного стиля в зависимости от характеристик и пр. Ход мыслей и выполнение заданий можно посмотреть здесь.
✔️ Прошел тренинг по управлению рисками. Запомнить: важно развивать вероятностное мышление, прорабатывать возможные сценарии и помнить, что наступление любого события всегда меньше единицы.
✔️ Зарефакторил старый проект. Полезная мысль: при рефакторинге и код-ревью в первую очередь обращаем внимание на то, как код влияет на остальную часть проекта, как с ним взаимодействует.
✔️ Продолжаю практиковаться в ООАП. Переосмыслил разницу между классами анализа и дизайна (отличный мог бы выйти пост в будущем, а кому интересно копнуть уже сейчас, может начать со статьи).
карьера
✔️ Перенял роль платформенного эксперта в своей вертикали (за несколько лет накопилось немало экспертизы в одном домене, которой могу делиться с коллегами и разгружать горизонтальную команду).
✔️ Написал свой первый TDR в компании. Утвержденный документ + последующая успешная реализация проекта = хорошая основа для будущего промо на следующий грейд, но, конечно, это не гарантия, а лишь один из кирпичиков.
✔️ Подготовился к перф-ревью, собрав все артефакты за полгода работы. По окончании июльского ревью подробнее поговорим о процессе и как к нему лучше готовиться, чтобы он прошел без боли.
посты
✔️ Как сделать продакшн стабильнее и что такое LSR (читать)
✔️ Моделирование угроз - инструмент для обеспечения безопасности ваших фичей (читать)
✔️ Кому нужно изучать проектирование систем и как к этому подступиться (читать)
✔️ Секрет хорошего дизайна и при чем здесь TDR и ADR (читать)
прочее
✔️ Поучаствовал в 2-х массовых забегах: на 7.195 км и 10 км. Кажется бег начинает входить в привычку. Важно к интеллектуальной активности добавлять любую физическую - они хорошо дружат, а вы сможете делать больше.
#результаты
навыки
✔️ Завершил больше половины курса по анализу систем, выполнил 4/5 всех заданий курса. Улучшил экспертизу в областях: работа с требованиями и внешними ограничениями, выделение основных частей системы при помощи Event Storming, выбор архитектурного стиля в зависимости от характеристик и пр. Ход мыслей и выполнение заданий можно посмотреть здесь.
✔️ Прошел тренинг по управлению рисками. Запомнить: важно развивать вероятностное мышление, прорабатывать возможные сценарии и помнить, что наступление любого события всегда меньше единицы.
✔️ Зарефакторил старый проект. Полезная мысль: при рефакторинге и код-ревью в первую очередь обращаем внимание на то, как код влияет на остальную часть проекта, как с ним взаимодействует.
✔️ Продолжаю практиковаться в ООАП. Переосмыслил разницу между классами анализа и дизайна (отличный мог бы выйти пост в будущем, а кому интересно копнуть уже сейчас, может начать со статьи).
карьера
✔️ Перенял роль платформенного эксперта в своей вертикали (за несколько лет накопилось немало экспертизы в одном домене, которой могу делиться с коллегами и разгружать горизонтальную команду).
✔️ Написал свой первый TDR в компании. Утвержденный документ + последующая успешная реализация проекта = хорошая основа для будущего промо на следующий грейд, но, конечно, это не гарантия, а лишь один из кирпичиков.
✔️ Подготовился к перф-ревью, собрав все артефакты за полгода работы. По окончании июльского ревью подробнее поговорим о процессе и как к нему лучше готовиться, чтобы он прошел без боли.
посты
✔️ Как сделать продакшн стабильнее и что такое LSR (читать)
✔️ Моделирование угроз - инструмент для обеспечения безопасности ваших фичей (читать)
✔️ Кому нужно изучать проектирование систем и как к этому подступиться (читать)
✔️ Секрет хорошего дизайна и при чем здесь TDR и ADR (читать)
прочее
✔️ Поучаствовал в 2-х массовых забегах: на 7.195 км и 10 км. Кажется бег начинает входить в привычку. Важно к интеллектуальной активности добавлять любую физическую - они хорошо дружат, а вы сможете делать больше.
#результаты
🔥2👍1
Google ворует имена
17 марта 2003 года вышла статья "Go! – A Logic Programming Language for
Implementing Multi-threaded Agents" (авторы: K.L. Clark и F.G. McCabe).
Был представлен новый мультипарадигменный язык "Go!", над которым велась работа на протяжении 10 лет.
Однако, большой популярности он не снискал. Язык довольно нишевый и преимущественно предназначен для академических целей и научных проектов.
Спустя 6 лет осенью 2009 Google представляет свой язык с одноименным названием за исключением пунктуации.
Авторы Go! почти сразу завели issue #9, где просили сменить название, так как такой язык уже существовал, но все тщетно.
Считаю, что про такие моменты важно знать в своей предметной области.
Вот так выглядит, например, «Hello World!» на Go!
А вот здесь можно прочитать про него краткую сводку.
Этично ли поступил Google? Или это просто бизнес и ничего личного?
17 марта 2003 года вышла статья "Go! – A Logic Programming Language for
Implementing Multi-threaded Agents" (авторы: K.L. Clark и F.G. McCabe).
Был представлен новый мультипарадигменный язык "Go!", над которым велась работа на протяжении 10 лет.
Однако, большой популярности он не снискал. Язык довольно нишевый и преимущественно предназначен для академических целей и научных проектов.
Спустя 6 лет осенью 2009 Google представляет свой язык с одноименным названием за исключением пунктуации.
Авторы Go! почти сразу завели issue #9, где просили сменить название, так как такой язык уже существовал, но все тщетно.
Считаю, что про такие моменты важно знать в своей предметной области.
Вот так выглядит, например, «Hello World!» на Go!
MODULE hello.
IMPORT standardio.
PREDICATE main.
main :-
standardio:write("Hello, World!").
А вот здесь можно прочитать про него краткую сводку.
Этично ли поступил Google? Или это просто бизнес и ничего личного?
👍3
Однажды Хемингуэй поспорил, что сможет написать самый короткий рассказ, способный напугать любого…
Он выиграл спор:Performance Review
Разберемся что это такое, почему наступает неожиданно и можно ли что-то с этим сделать?
Если кратко, то это процесс подведения итогов работы за определенный период. Подробнее можно найти здесь.
Наличие такого процесса говорит об определенном уровне зрелости компании, но он должен работать правильно, чтобы не доставлять вам хлопот(ведь вы пришли код писать, а не отчеты для менеджеров) .
Всегда стараюсь изучать как это устроено у лидеров индустрии. Но в этот раз задача оказалась непростой, MAANG-компаний не любят открыто делиться тем, что работает, но кое-что найти все-таки удалось.
Раньше, по утверждениям источников, процесс в Google выглядел в точности как и в Авито, но с небольшими изменениями.
Рассмотрим основные этапы.
Google Performance Review
В год происходит 2 ревью: превью по окончании первого семестра и полное ревью между октябрем и ноябрем. На полном ревью добавляется оценка по методу 360, на котором коллеги дают обратную связь друг другу и оценивают качество взаимодействия.
Разберем подробно полный процесс ревью.
1. Период самооценки
Это фактически отчет о своих достижениях за прошедший период. Метрики и привязки к ОКРам обязательны, иначе зачем все это, если не приносит бизнесу результат?
Самое пикантное, что все достижения нужно уложить в текстовое поле размером 512 символов :)
Здесь передаю привет своим коллегам, с которыми мы страдаем, тщетно пытаясь ужаться, но уже в более приятную цифру - 800.
2. Период оценки 360 (отсутствует на превью)
На этом этапе коллеги (которых ты пригласишь в ревью) оценят качество взаимодействия с тобой: что понравилось в работе, а что можно улучшить. Ты, в свою очередь, также даешь оценку коллегам и пишешь обратную связь.
3. Период калибровок
Когда все отчеты написаны, менеджеры выставляют драфтовые оценки своим подчиненным. Затем на общей встрече менеджеров драфтовая оценка калибруется (=выравнивается), чтобы сотрудник получил справедливый отзыв о своей работе.
4. Обсуждение результатов
На этом этапе вы обсуждаете со своим руководителем итоги процесса, составляете план развития, обмениваетесь обратной связью.
В Авито процесс устроен аналогично, только у нас нет превью, а есть 2 полноценных перформанс ревью.
Здесь можно посмотреть кратко как процесс устроен в другом Биг Техе: Meta, Apple, Amazon, Netflix.
Из этой же статьи мы узнаем, что Google в 2022 году сменил свой старый процесс на Googler Reviews and Development (GRAD). Самое главное нововведение - работа с ожиданиями и фокус на саморазвитии с построением карьеры в компании.
У Performance Review есть очень неприятное свойство: он наступает неожиданно и обычно застает тебя врасплох. Механика такая же как у лета: вот был первый день - момент - и вот мы уже перешагнули половину и движемся к завершению...
На неделе у меня заканчивается очередной период перформанс ревью. И каким бы нелюбимым для многих он не был, я вижу в нем больше преимуществ, чем недостатков.
Как с комфортом подойти к этому процессу, чтобы извлечь максимальную пользу и не тратить много времени на прохождение, напишу в продолжении.
Он выиграл спор:
Разберемся что это такое, почему наступает неожиданно и можно ли что-то с этим сделать?
Если кратко, то это процесс подведения итогов работы за определенный период. Подробнее можно найти здесь.
Наличие такого процесса говорит об определенном уровне зрелости компании, но он должен работать правильно, чтобы не доставлять вам хлопот
Всегда стараюсь изучать как это устроено у лидеров индустрии. Но в этот раз задача оказалась непростой, MAANG-компаний не любят открыто делиться тем, что работает, но кое-что найти все-таки удалось.
Раньше, по утверждениям источников, процесс в Google выглядел в точности как и в Авито, но с небольшими изменениями.
Рассмотрим основные этапы.
Google Performance Review
В год происходит 2 ревью: превью по окончании первого семестра и полное ревью между октябрем и ноябрем. На полном ревью добавляется оценка по методу 360, на котором коллеги дают обратную связь друг другу и оценивают качество взаимодействия.
Разберем подробно полный процесс ревью.
1. Период самооценки
Это фактически отчет о своих достижениях за прошедший период. Метрики и привязки к ОКРам обязательны, иначе зачем все это, если не приносит бизнесу результат?
Самое пикантное, что все достижения нужно уложить в текстовое поле размером 512 символов :)
Здесь передаю привет своим коллегам, с которыми мы страдаем, тщетно пытаясь ужаться, но уже в более приятную цифру - 800.
2. Период оценки 360 (отсутствует на превью)
На этом этапе коллеги (которых ты пригласишь в ревью) оценят качество взаимодействия с тобой: что понравилось в работе, а что можно улучшить. Ты, в свою очередь, также даешь оценку коллегам и пишешь обратную связь.
3. Период калибровок
Когда все отчеты написаны, менеджеры выставляют драфтовые оценки своим подчиненным. Затем на общей встрече менеджеров драфтовая оценка калибруется (=выравнивается), чтобы сотрудник получил справедливый отзыв о своей работе.
4. Обсуждение результатов
На этом этапе вы обсуждаете со своим руководителем итоги процесса, составляете план развития, обмениваетесь обратной связью.
В Авито процесс устроен аналогично, только у нас нет превью, а есть 2 полноценных перформанс ревью.
Здесь можно посмотреть кратко как процесс устроен в другом Биг Техе: Meta, Apple, Amazon, Netflix.
Из этой же статьи мы узнаем, что Google в 2022 году сменил свой старый процесс на Googler Reviews and Development (GRAD). Самое главное нововведение - работа с ожиданиями и фокус на саморазвитии с построением карьеры в компании.
У Performance Review есть очень неприятное свойство: он наступает неожиданно и обычно застает тебя врасплох. Механика такая же как у лета: вот был первый день - момент - и вот мы уже перешагнули половину и движемся к завершению...
На неделе у меня заканчивается очередной период перформанс ревью. И каким бы нелюбимым для многих он не был, я вижу в нем больше преимуществ, чем недостатков.
Как с комфортом подойти к этому процессу, чтобы извлечь максимальную пользу и не тратить много времени на прохождение, напишу в продолжении.
👍3🔥1
Подчиняем performance review
В текущей компании прошедшее ревью для меня стало четвертым, а самыми сложными были первые два, когда еще не до конца знаком с процессом и не понимаешь чего именно от тебя ожидают.
Что мне помогает и почему я уже начал готовиться к следующему?
Свой опыт я решил сгруппировать по периодам, которые можно рассматривать отдельно на каждом из этапов ревью.
1️⃣ Готовимся
период: окончание перф. ревью -> начало следующего перф. ревью
- ) Оставляйте цифровой след. Это могут быть любые артефакты: пост с договоренностями после встречи, тред с активным обсуждением, комментарий в Jira с результатами ресерча. Когда сядете за написание очередного ревью, обязательно скажете вчерашнему себе спасибо.
- ) Сохраняйте ссылки на артефакты. Сделайте себе единую точку входа, например, в заметках. Идеальным случаем не сваливать все в кучу, а сортировать по проектам/инициативам. Так у вас будет фактически готовый шаблон для будущего ревью, останется только обогатить контекстом и добавить цифр.
Я использую Obsidian, но подойдет что угодно. Даже простой список с перечислением и небольшими комментариями лучше, чем ничего.
Этому сложно следовать, так как думаете, что потом сможете все найти поиском по мессенджеру, но, во первых, очень легко через полгода забыть что вообще делали, а во вторых, сильно сэкономите себе время.
- ) Постоянно сверяйтесь с планом своего развития. Задавайте вопросы: Туда ли вы движетесь? Приближает ли выполнение ежедневных задач к цели? Можете ли выйти за рамки своей ответственности, делая какую-то задачу и будет ли кому-то еще это полезно?
Если понимаете, что сбились с пути и увязли в рутине, то обязательно обсудите с руководителем предмет беспокойства. Вместе вы сможете найти решение, но лучше всего - если самостоятельно предложите возможное, которое затем подкорректируете.
2️⃣ Пишем
период: начало перф. ревью -> окончание периода оценки коллег
- ) Если все время вели структурированные заметки, то все, что вам нужно: достать командные цели на прошедшие кварталы и соотнести их со своими артефактами (предполагаем, что руководитель и продакт позаботились о том, чтобы выполняемые вами задачи соотносились с роадмапом команды и приносили результат бизнесу).
Работая в продуктовой команде, нам нужны сухие цифры о выполнении ОКР'ов и, например, аналитика по окончании экспериментов. В команде инфраструктуры, очевидно, у вас будут другие метрики результата, но смысл один.
Формула следующая:
<цель/окр/инициатива/проект> + <ваш вклад: сервис/фича/документация> = <метрики результата>
- ) Используйте поиск по таск-трекинговой системе. В Jira, например, можно фильтровать свои таски за прошедший период, используя JQL.
(5 реакций и дам готовый фильтр на JQL, который использую)
- ) Если для написания ревью используете корпоративный инструмент, то лучше чаще делайте бэкап локально (в заметки). Нет ничего обиднее, чем потерять уже написанный документ.
- ) Вычитка финального ревью обязательна!
3️⃣ Анализируем
период: окончание периода оценки коллег -> окончание перф. ревью
- ) Обращаем внимание на ОС от руководителя и коллег, что было хорошо, а что можно улучшить. Делаем на это упор в следующем периоде.
- ) Самый важный вопрос: "Куда мы хотим прийти через 6 месяцев?". Ответ напрямую влияет на будущую работу. Важно понимать, что для перехода на следующий грейд требуются совершенно другие акценты, нежели чем классическая работа на "хороший" результат.
Обозначьте цель и следуйте к ней. Если это - промо, то обсудите с тимлидом заранее и уже начинайте над этим работать.
> > >
Описал, что работает для меня. Если в вашей компании есть похожая практика и у вас этот процесс связан с неприятными эмоциями, то попробуйте описанный выше алгоритм, а потом поделитесь фидбеком. Скорее всего, вы что-то оптимизируете под себя, универсального решения нет.
Какой у вас «секрет» написания ревью или вы счастливо живете без него?
P.S.: Я показал процесс со стороны инженера. У руководителя все гораздо "интереснее".
Пусть результат вашей работы превзойдет все мыслимые ожидания менеджеров!
В текущей компании прошедшее ревью для меня стало четвертым, а самыми сложными были первые два, когда еще не до конца знаком с процессом и не понимаешь чего именно от тебя ожидают.
Что мне помогает и почему я уже начал готовиться к следующему?
Свой опыт я решил сгруппировать по периодам, которые можно рассматривать отдельно на каждом из этапов ревью.
1️⃣ Готовимся
период: окончание перф. ревью -> начало следующего перф. ревью
- ) Оставляйте цифровой след. Это могут быть любые артефакты: пост с договоренностями после встречи, тред с активным обсуждением, комментарий в Jira с результатами ресерча. Когда сядете за написание очередного ревью, обязательно скажете вчерашнему себе спасибо.
- ) Сохраняйте ссылки на артефакты. Сделайте себе единую точку входа, например, в заметках. Идеальным случаем не сваливать все в кучу, а сортировать по проектам/инициативам. Так у вас будет фактически готовый шаблон для будущего ревью, останется только обогатить контекстом и добавить цифр.
Я использую Obsidian, но подойдет что угодно. Даже простой список с перечислением и небольшими комментариями лучше, чем ничего.
Этому сложно следовать, так как думаете, что потом сможете все найти поиском по мессенджеру, но, во первых, очень легко через полгода забыть что вообще делали, а во вторых, сильно сэкономите себе время.
- ) Постоянно сверяйтесь с планом своего развития. Задавайте вопросы: Туда ли вы движетесь? Приближает ли выполнение ежедневных задач к цели? Можете ли выйти за рамки своей ответственности, делая какую-то задачу и будет ли кому-то еще это полезно?
Если понимаете, что сбились с пути и увязли в рутине, то обязательно обсудите с руководителем предмет беспокойства. Вместе вы сможете найти решение, но лучше всего - если самостоятельно предложите возможное, которое затем подкорректируете.
2️⃣ Пишем
период: начало перф. ревью -> окончание периода оценки коллег
- ) Если все время вели структурированные заметки, то все, что вам нужно: достать командные цели на прошедшие кварталы и соотнести их со своими артефактами (предполагаем, что руководитель и продакт позаботились о том, чтобы выполняемые вами задачи соотносились с роадмапом команды и приносили результат бизнесу).
Работая в продуктовой команде, нам нужны сухие цифры о выполнении ОКР'ов и, например, аналитика по окончании экспериментов. В команде инфраструктуры, очевидно, у вас будут другие метрики результата, но смысл один.
Формула следующая:
<цель/окр/инициатива/проект> + <ваш вклад: сервис/фича/документация> = <метрики результата>
- ) Используйте поиск по таск-трекинговой системе. В Jira, например, можно фильтровать свои таски за прошедший период, используя JQL.
(5 реакций и дам готовый фильтр на JQL, который использую)
- ) Если для написания ревью используете корпоративный инструмент, то лучше чаще делайте бэкап локально (в заметки). Нет ничего обиднее, чем потерять уже написанный документ.
- ) Вычитка финального ревью обязательна!
3️⃣ Анализируем
период: окончание периода оценки коллег -> окончание перф. ревью
- ) Обращаем внимание на ОС от руководителя и коллег, что было хорошо, а что можно улучшить. Делаем на это упор в следующем периоде.
- ) Самый важный вопрос: "Куда мы хотим прийти через 6 месяцев?". Ответ напрямую влияет на будущую работу. Важно понимать, что для перехода на следующий грейд требуются совершенно другие акценты, нежели чем классическая работа на "хороший" результат.
Обозначьте цель и следуйте к ней. Если это - промо, то обсудите с тимлидом заранее и уже начинайте над этим работать.
> > >
Описал, что работает для меня. Если в вашей компании есть похожая практика и у вас этот процесс связан с неприятными эмоциями, то попробуйте описанный выше алгоритм, а потом поделитесь фидбеком. Скорее всего, вы что-то оптимизируете под себя, универсального решения нет.
Какой у вас «секрет» написания ревью или вы счастливо живете без него?
P.S.: Я показал процесс со стороны инженера. У руководителя все гораздо "интереснее".
Пусть результат вашей работы превзойдет все мыслимые ожидания менеджеров!
🔥9
Маленькие шаги - основа вашей эффективности
Здорово разрабатывать сложные системы, но еще очень приятно автоматизировать мелкую рутину.
Один из примеров - поиск выполненных задач за прошедший период для перформанс ревью.
Делюсь готовым JQL-запросом для получения завершенных задач связанных с вами за последние 6 месяцев в Jira, которым пользуюсь регулярно:
Можно настроить фильтр, сохранить в закладки и держать свои выполненные задачи под рукой.
Сами по себе подобные хитрости несут мало практической пользы, но когда вы их встраиваете в работающую для себя систему (подходите системно к перф. ревью, например), то достигается синергетический эффект.
Здорово разрабатывать сложные системы, но еще очень приятно автоматизировать мелкую рутину.
Один из примеров - поиск выполненных задач за прошедший период для перформанс ревью.
Делюсь готовым JQL-запросом для получения завершенных задач связанных с вами за последние 6 месяцев в Jira, которым пользуюсь регулярно:
(created >= startOfDay(-180) OR resolution changed after startOfDay(-180) OR status changed after startOfDay(-180)) AND (reporter = currentUser() OR assignee was currentUser()) ORDER BY resolved ASC, updated ASC
Можно настроить фильтр, сохранить в закладки и держать свои выполненные задачи под рукой.
Сами по себе подобные хитрости несут мало практической пользы, но когда вы их встраиваете в работающую для себя систему (подходите системно к перф. ревью, например), то достигается синергетический эффект.
🔥6
Анализ систем. Финал
Вчера получил сертификат об окончании курса по анализу систем, так как не просто его прослушал, но и выполнил все практические задания (решения выкладывал на github).
Курс мне понравился. Из основных ожиданий было получить инструмент как системно подходить к проектированию любой системы. И такой инструмент у меня теперь есть (EventStorming, стратегический DDD и другие), а также есть понимание ("big picture") всего жизненного цикла разрабатываемой системы с оглядкой на постоянно меняющиеся требования и консерны стейкхолдеров.
Формат курса
Меня поразила уникальность предлагаемого формата по обучению: никаких видеоуроков, только большой текст и работа с обратной связью. Удивительно, но могу заверить, что это лучше всего работает!
Части курса поделены по неделям, на каждой из которых дается лонгрид на 100+- страниц и ДЗ по окончанию модуля. Плюс есть возможность общаться и получать ответы через тг-канал курса у автора (очень быстрая обратная связь). Завершение очередного модуля сопровождается разбором ДЗ в формате вебинара, где обсуждаются самые распространенные ошибки.
Есть также механика проверок работ коллег (peer-to-peer). Такой подход помогает лучше закрепить материал, заставляя примерить на себя роль учителя и помогая взглянуть на решаемое задание совершенно иначе.
На курсе были разные тарифы. Я выбрал тот, который отличается подробной ОС по каждому ДЗ - и это было невероятно полезно. Когда проверял чужие работы, то видел, что автор дает краткий комментарий с пунктами, требующими внимания, но в моем случае все было детально расписано - и такой фидбек был очень ценен.
Рефлексия
В последнем ДЗ предлагалось поделиться рефлексией с оглядкой на свою самую первую систему в курсе. Прикрепляю основную выдержку ниже (полная версия):
Идеи и подходы, которые интересно внедрить в будущем:
- Думать на уровне поддоменов и ограниченных контекстов. Понравилось, что такой подход учит собирать конкретный бизнесовый контекст, вытекающий из требований к системе, в одном месте. Мыслить на уровне поддоменов - выглядит как системный подход к анализу и проектированию любой системы.
- Event Storming обязательно станет одним из постоянных инструментов в моем арсенале. Интересно его попробовать применить в своей команде для проектирования новой системы.
- Не всегда одинаковые по смыслу системы, например, в домене биллинга, должны располагаться в одном микросервисе. Иногда полезно их разделить. Тут важно смотреть на контекст, в котором они существуют. Возможно, он очень специфичный для каждой из систем.
- Характеристики системы определяют архитектурный стиль, а также помогают при распиле монолита.
- Каждое требование важно. Нужно прорабатывать каждый консерн стейкхолдеров и каждый пункт требований еще на моменте анализа.
- При наличии неопределенности в требованиях и любых сомнениях по работе будущей системы - задавайте вопросы.
- Оставляем артефакты принятых решений. В идеале - делать ADR по каждому.
Еще очень понравилась нотация C4, про которую узнал на курсе. Теперь рисую схемы только по ней (использую уровень контейнеров C2). Потихоньку готовлю пост про C4 и про использования DSL для создания схем - полезно для тех, кто устал рисовать и выравнивать стрелки 🤓
Вчера получил сертификат об окончании курса по анализу систем, так как не просто его прослушал, но и выполнил все практические задания (решения выкладывал на github).
Курс мне понравился. Из основных ожиданий было получить инструмент как системно подходить к проектированию любой системы. И такой инструмент у меня теперь есть (EventStorming, стратегический DDD и другие), а также есть понимание ("big picture") всего жизненного цикла разрабатываемой системы с оглядкой на постоянно меняющиеся требования и консерны стейкхолдеров.
Формат курса
Меня поразила уникальность предлагаемого формата по обучению: никаких видеоуроков, только большой текст и работа с обратной связью. Удивительно, но могу заверить, что это лучше всего работает!
Части курса поделены по неделям, на каждой из которых дается лонгрид на 100+- страниц и ДЗ по окончанию модуля. Плюс есть возможность общаться и получать ответы через тг-канал курса у автора (очень быстрая обратная связь). Завершение очередного модуля сопровождается разбором ДЗ в формате вебинара, где обсуждаются самые распространенные ошибки.
Есть также механика проверок работ коллег (peer-to-peer). Такой подход помогает лучше закрепить материал, заставляя примерить на себя роль учителя и помогая взглянуть на решаемое задание совершенно иначе.
На курсе были разные тарифы. Я выбрал тот, который отличается подробной ОС по каждому ДЗ - и это было невероятно полезно. Когда проверял чужие работы, то видел, что автор дает краткий комментарий с пунктами, требующими внимания, но в моем случае все было детально расписано - и такой фидбек был очень ценен.
Рефлексия
В последнем ДЗ предлагалось поделиться рефлексией с оглядкой на свою самую первую систему в курсе. Прикрепляю основную выдержку ниже (полная версия):
Идеи и подходы, которые интересно внедрить в будущем:
- Думать на уровне поддоменов и ограниченных контекстов. Понравилось, что такой подход учит собирать конкретный бизнесовый контекст, вытекающий из требований к системе, в одном месте. Мыслить на уровне поддоменов - выглядит как системный подход к анализу и проектированию любой системы.
- Event Storming обязательно станет одним из постоянных инструментов в моем арсенале. Интересно его попробовать применить в своей команде для проектирования новой системы.
- Не всегда одинаковые по смыслу системы, например, в домене биллинга, должны располагаться в одном микросервисе. Иногда полезно их разделить. Тут важно смотреть на контекст, в котором они существуют. Возможно, он очень специфичный для каждой из систем.
- Характеристики системы определяют архитектурный стиль, а также помогают при распиле монолита.
- Каждое требование важно. Нужно прорабатывать каждый консерн стейкхолдеров и каждый пункт требований еще на моменте анализа.
- При наличии неопределенности в требованиях и любых сомнениях по работе будущей системы - задавайте вопросы.
- Оставляем артефакты принятых решений. В идеале - делать ADR по каждому.
Еще очень понравилась нотация C4, про которую узнал на курсе. Теперь рисую схемы только по ней (использую уровень контейнеров C2). Потихоньку готовлю пост про C4 и про использования DSL для создания схем - полезно для тех, кто устал рисовать и выравнивать стрелки 🤓
🔥7
3 в ряд 🍒🍒🍒
В рамках экспериментального погружения в ООАП написал консольную игру.
Не все удалось реализовать согласно первоначальной задумке, многое упростил. В основном мешало, что уже несколько лет не работаю в ООП-парадигме и на смену C# пришел Go.
Однако очень помогло описание архитектуры, с которого начинал проектирование, то есть формально заставлял себя следовать тому, что я когда-то уже проанализировал и запроектировал. Из интересных открытий: во время анализа отбраковал некоторые классы, которые (как мне казалось) понадобились во время реализации. Но когда написал код, то понял, что все-таки отбраковал их правильно и они на самом деле не нужны.
Крайне важная вещь, про которую не устаю говорить: не стоит смешивать несколько фокусов (в моем случае параллельно шел Анализ систем) и, очевидно, это плохая практика.
Запомнить: время на проектирование и анализ всегда следует тратить больше, тщательнее продумывая взаимодействия между модулями. Это действительно вам поможет на этапе реализации.
В рамках экспериментального погружения в ООАП написал консольную игру.
Не все удалось реализовать согласно первоначальной задумке, многое упростил. В основном мешало, что уже несколько лет не работаю в ООП-парадигме и на смену C# пришел Go.
Однако очень помогло описание архитектуры, с которого начинал проектирование, то есть формально заставлял себя следовать тому, что я когда-то уже проанализировал и запроектировал. Из интересных открытий: во время анализа отбраковал некоторые классы, которые (как мне казалось) понадобились во время реализации. Но когда написал код, то понял, что все-таки отбраковал их правильно и они на самом деле не нужны.
Крайне важная вещь, про которую не устаю говорить: не стоит смешивать несколько фокусов (в моем случае параллельно шел Анализ систем) и, очевидно, это плохая практика.
Запомнить: время на проектирование и анализ всегда следует тратить больше, тщательнее продумывая взаимодействия между модулями. Это действительно вам поможет на этапе реализации.
👍5🔥5❤1
Июль 2024:
навыки
✔️ Завершил курс по анализу систем. Выполнил 5/5 всех заданий курса, проверил 12 работ других студентов и получил финальный сертификат.
✔️ Завершил курс по ООАП и написал консольную игру (3 в ряд). Рефлексия в прошлом посте.
✔️ Попрактиковался в приведении запутанного интерфейса в более выразительный.
карьера
✔️ Получил хороший фидбек по окончании перф-ревью. Коллеги отметили качество коммуникации и проявление инициативы по нашим стримам.
✔️ Написанный TDR по новому сервису породил активную дискуссию, особенно спорным стал выбор БД (NoSQL VS SQL) - документ ушел на второй круг. Цель на ближайший спринт - качественно обработать все комментарии и согласовать финальное решение, чтобы приступить к разработке.
посты
✔️ Как устроен TDR изнутри (Tech Design Review) (читать)
✔️ Чем отличается Go! от Go (читать)
✔️ Performance Review в Big Tech (читать)
✔️ Как готовиться и писать Performance Review (читать)
✔️ Полезный фильтр для ваших задач в Jira (читать)
✔️ Анализ систем. Что унести с собой? (читать)
прочее
✔️ Поучаствовал в двух массовых забегах: на 10 км. Лучший результат - 52:20 (5:14/км). Бег определенно вошел в привычку - помогает хорошо разгрузиться. На сентябрь запланировал полумарафон, надеюсь, хватит времени на подготовку.
#результаты
навыки
✔️ Завершил курс по анализу систем. Выполнил 5/5 всех заданий курса, проверил 12 работ других студентов и получил финальный сертификат.
✔️ Завершил курс по ООАП и написал консольную игру (3 в ряд). Рефлексия в прошлом посте.
✔️ Попрактиковался в приведении запутанного интерфейса в более выразительный.
карьера
✔️ Получил хороший фидбек по окончании перф-ревью. Коллеги отметили качество коммуникации и проявление инициативы по нашим стримам.
✔️ Написанный TDR по новому сервису породил активную дискуссию, особенно спорным стал выбор БД (NoSQL VS SQL) - документ ушел на второй круг. Цель на ближайший спринт - качественно обработать все комментарии и согласовать финальное решение, чтобы приступить к разработке.
посты
✔️ Как устроен TDR изнутри (Tech Design Review) (читать)
✔️ Чем отличается Go! от Go (читать)
✔️ Performance Review в Big Tech (читать)
✔️ Как готовиться и писать Performance Review (читать)
✔️ Полезный фильтр для ваших задач в Jira (читать)
✔️ Анализ систем. Что унести с собой? (читать)
прочее
✔️ Поучаствовал в двух массовых забегах: на 10 км. Лучший результат - 52:20 (5:14/км). Бег определенно вошел в привычку - помогает хорошо разгрузиться. На сентябрь запланировал полумарафон, надеюсь, хватит времени на подготовку.
#результаты
❤9👍1
Что может пойти не так?
Провел первую в команде сессию по моделированию угроз для перспективного сервиса.
Встреча была запланирована на час, но уже на 45-й минуте стало понятно, что на сессию нужно закладывать 1,5-2 часа, чтобы спокойно все продумать и не торопиться.
В итоге сессию разбили на две по одному часу, в ходе которых удалось взглянуть на сервис с разных сторон. Было продумано множество потенциально неприятных сценариев, которые с той или иной вероятностью могли бы случиться. Здорово, что в Биг Техе многие уязвимости закрываются инфраструктурными командами, но все равно их важно проговорить и явно зафиксировать как они будут учитываться.
Внутреннее сообщество компании продвигающее идеологию чемпионов по безопасности и рассказывающее, как проводить моделирование угроз в команде предлагает шаблон, с помощью которого рекомендуется проводить эту сессию. Это большой хост, на котором слева расположена библиотека атак (основные уязвимости для брейншторма), в центре - пространство для схемы проектируемого сервиса; а справа - цветная область, разделенная на три зоны для группировки угроз по статусам: сразу учитываем в разработке, оставляем на будущее, принимаем риски.
Такой фреймворк по моделированию угроз неплох, но есть особенности, на которые важно обращать внимание, иначе можно неэффективно потратить время:
1️⃣ Этот момент нигде явно не зафиксирован (он подразумевается): всю сессию предлагается проводить под девизом "Что может пойти не так?". Но держите постоянно в голове, что вы рассматриваете исключительно уязвимости, то есть потенциальные атаки (их вектор). Если вдруг всплывает идея про какой-либо неучтенный риск, то фиксируйте его рядом и двигайтесь дальше по фреймворку, иначе можно сильно уйти в сторону.
2️⃣ Строго следуем плану. Если используем каталог атак, то план такой: примеряем атаку из каталога на каждый узел своей функциональности -> если проблема вероятна, то располагаем рядом соответствующую карточку -> решаем что делать по каждой из проблем -> определяемся со статусом угроз (зона справа).
3️⃣ Каталог атак или методику, по которой определяем угрозы желательно продумать заранее. Все команды разные и желательно выбирать инструмент, который лучше подойдет вашей команде. У меня после использования предлагаемого каталога атак появилось сильное желание переработать его под свою, например, используя STRIDE, предлагаемый Microsoft.
Еще раз обращаю внимание на п.1. Крайне важно ограничивать рассматриваемый скоуп (область - например, угрозы безопасности).
Легко увлечься и начать обсуждать возможные риски и уязвимости, но бейте себя по рукам - сохраняйте фокус только на угрозах безопасности. Мне, к сожалению, в первый раз не удалось качественно профасилитирировать процесс, поэтому мы быстро уходили в обсуждение всевозможных рисков за пределами основного фокуса.
Оценка рисков (risk assessment) - похожий, но совершенно другой процесс. Он подразумевает более широкий подход применительно ко всем рискам, а не только угрозам безопасности. И у него есть свои инструменты для проведения сессии (матрица рисков, Risk-Based Testing и другие).
Из текущего опыта: сначала проведите оценку рисков, а затем моделируйте угрозы. Это позволить избежать обсуждений нецелевых рисков и сфокусироваться на безопасности.
#безопасность
Провел первую в команде сессию по моделированию угроз для перспективного сервиса.
Встреча была запланирована на час, но уже на 45-й минуте стало понятно, что на сессию нужно закладывать 1,5-2 часа, чтобы спокойно все продумать и не торопиться.
В итоге сессию разбили на две по одному часу, в ходе которых удалось взглянуть на сервис с разных сторон. Было продумано множество потенциально неприятных сценариев, которые с той или иной вероятностью могли бы случиться. Здорово, что в Биг Техе многие уязвимости закрываются инфраструктурными командами, но все равно их важно проговорить и явно зафиксировать как они будут учитываться.
Внутреннее сообщество компании продвигающее идеологию чемпионов по безопасности и рассказывающее, как проводить моделирование угроз в команде предлагает шаблон, с помощью которого рекомендуется проводить эту сессию. Это большой хост, на котором слева расположена библиотека атак (основные уязвимости для брейншторма), в центре - пространство для схемы проектируемого сервиса; а справа - цветная область, разделенная на три зоны для группировки угроз по статусам: сразу учитываем в разработке, оставляем на будущее, принимаем риски.
Такой фреймворк по моделированию угроз неплох, но есть особенности, на которые важно обращать внимание, иначе можно неэффективно потратить время:
1️⃣ Этот момент нигде явно не зафиксирован (он подразумевается): всю сессию предлагается проводить под девизом "Что может пойти не так?". Но держите постоянно в голове, что вы рассматриваете исключительно уязвимости, то есть потенциальные атаки (их вектор). Если вдруг всплывает идея про какой-либо неучтенный риск, то фиксируйте его рядом и двигайтесь дальше по фреймворку, иначе можно сильно уйти в сторону.
2️⃣ Строго следуем плану. Если используем каталог атак, то план такой: примеряем атаку из каталога на каждый узел своей функциональности -> если проблема вероятна, то располагаем рядом соответствующую карточку -> решаем что делать по каждой из проблем -> определяемся со статусом угроз (зона справа).
3️⃣ Каталог атак или методику, по которой определяем угрозы желательно продумать заранее. Все команды разные и желательно выбирать инструмент, который лучше подойдет вашей команде. У меня после использования предлагаемого каталога атак появилось сильное желание переработать его под свою, например, используя STRIDE, предлагаемый Microsoft.
Еще раз обращаю внимание на п.1. Крайне важно ограничивать рассматриваемый скоуп (область - например, угрозы безопасности).
Легко увлечься и начать обсуждать возможные риски и уязвимости, но бейте себя по рукам - сохраняйте фокус только на угрозах безопасности. Мне, к сожалению, в первый раз не удалось качественно профасилитирировать процесс, поэтому мы быстро уходили в обсуждение всевозможных рисков за пределами основного фокуса.
Оценка рисков (risk assessment) - похожий, но совершенно другой процесс. Он подразумевает более широкий подход применительно ко всем рискам, а не только угрозам безопасности. И у него есть свои инструменты для проведения сессии (матрица рисков, Risk-Based Testing и другие).
Из текущего опыта: сначала проведите оценку рисков, а затем моделируйте угрозы. Это позволить избежать обсуждений нецелевых рисков и сфокусироваться на безопасности.
#безопасность
👍3
Осторожно: AI. Как могут обмануть ассистенты и что с этим делать?
Еще в прошлом году хотел написать большой пост с метанием камней в AI, так как первые секунды общения с "чатом" вызывали эйфорию от потенциальных возможностей, но потом сказка рушилась, когда дело доходило до реальной практики.
Но с тех пор ассистенты серьезно набрали вес, а их качество и доступность продолжают улучшаться. Поэтому хочется поделиться в каких задачах нахожу использование AI оправданным.
ChatGPT почти мне заменил гугл в бытовых вопросах поиска информации (последний обычно использую для верификации и поиска источника), но есть также профессиональные кейсы использования: весной писал, как Llama3 помогала с вычиткой резюме.
А сегодня попробуем найти решение инженерной задачи с помощью AI и разберем на что важно обращать внимание. Использоваться будет GPT-4o, как самый сообразительный из тех, на ком я тестировал (Llama3.1, к сожалению, не смогла выдать правильное решение).
Задача
В повседневной работе, особенно когда пишешь юнит-тесты, возникает необходимость сравнивать JSON-объекты (различные конфиги, например). Зачастую это массив байт, json.RawMessage, ссылка на массив и др.
Есть объект с ожидаемой структурой, который мы написали сами, а есть другой - который получаем после результата работы программы.
Когда мы пытаемся сравнить объекты, то сталкиваемся со следующим:
1. Порядок ключей может быть произвольный во втором объекте.
2. Отступы или форматирование в 2-х json-ах могут сильно отличаться, а так как мы сравниваем массивы байт, то все влияет на результат.
Идем к AI просить помощи. Мой запрос:
Получаем подробный ответ с объяснениями и рабочим кодом!
Для решения задачи нам рекомендуют "нормализовать" 2 json'а. И это отличный совет, а вот предлагаемую реализацию разберем подробнее.
Если говорить про нормализацию в вакууме, то как будто все хорошо, но у нас же задача сравнить 2 объекта.
Поэтому меня зацепили моменты:
1. Множественный маршалинг: сначала в одну сторону, а потом и в другую (не самая дешевая операция). Почему мы не можем сравнить анмаршаленные объекты?
2. Уже на уровне придирки, но все же. Равенство объектов предлагается находить через рефлексию - для тестов подойдет, но вот для продакшн среды возможно есть более оптимальные решения.
Интересное наблюдение, если вторым запросом поинтересоваться:
То ассистент догадается, что можно обойтись без последнего маршалинга и возможно даже подскажет, что можно вместо map[string]interface{} использовать interface{}.
Вывод
Таким образом, чтобы решить одну задачу с помощью ассистента, у нас появляется 2 задачи, одна из которых - правильно сформулировать запрос или ряд запросов, чтобы получить качественное решение.
Важно помнить:
1. Ассистенты способны решать задачи, но чтобы делать это хорошо, нужен качественный запрос и контекст, формирование которых может быть трудоемким.
2. Ассистент работает поверхностно и прямолинейно с тем контекстом, который вы в него загрузили.
3. Всегда проверяйте предлагаемое решение, особенно если это код. В этом вопросе нужен опыт, поэтому для новичков не рекомендую увлекаться написанием кода с AI.
Если тема будет интересна, то постараюсь собирать подобные истории и делиться тем, как AI помогает в повседневной работе и где он наиболее эффективен.
#ai
Еще в прошлом году хотел написать большой пост с метанием камней в AI, так как первые секунды общения с "чатом" вызывали эйфорию от потенциальных возможностей, но потом сказка рушилась, когда дело доходило до реальной практики.
Но с тех пор ассистенты серьезно набрали вес, а их качество и доступность продолжают улучшаться. Поэтому хочется поделиться в каких задачах нахожу использование AI оправданным.
ChatGPT почти мне заменил гугл в бытовых вопросах поиска информации (последний обычно использую для верификации и поиска источника), но есть также профессиональные кейсы использования: весной писал, как Llama3 помогала с вычиткой резюме.
А сегодня попробуем найти решение инженерной задачи с помощью AI и разберем на что важно обращать внимание. Использоваться будет GPT-4o, как самый сообразительный из тех, на ком я тестировал (Llama3.1, к сожалению, не смогла выдать правильное решение).
Задача
В повседневной работе, особенно когда пишешь юнит-тесты, возникает необходимость сравнивать JSON-объекты (различные конфиги, например). Зачастую это массив байт, json.RawMessage, ссылка на массив и др.
Есть объект с ожидаемой структурой, который мы написали сами, а есть другой - который получаем после результата работы программы.
Когда мы пытаемся сравнить объекты, то сталкиваемся со следующим:
1. Порядок ключей может быть произвольный во втором объекте.
2. Отступы или форматирование в 2-х json-ах могут сильно отличаться, а так как мы сравниваем массивы байт, то все влияет на результат.
Идем к AI просить помощи. Мой запрос:
I need to compare two objects containing json.RawMessage in Golang. But I get a mess because of different spaces in the data. How can I solve it?
Provide the most effective and straightforward way to do it.
Получаем подробный ответ с объяснениями и рабочим кодом!
Для решения задачи нам рекомендуют "нормализовать" 2 json'а. И это отличный совет, а вот предлагаемую реализацию разберем подробнее.
// NormalizeJSON takes a json.RawMessage, unmarshals it into a generic map,
// and then marshals it back to a json.RawMessage to normalize it.
func NormalizeJSON(raw json.RawMessage) (json.RawMessage, error) {
var obj map[string]interface{}
if err := json.Unmarshal(raw, &obj); err != nil {
return nil, err
}
normalized, err := json.Marshal(obj)
if err != nil {
return nil, err
}
return normalized, nil
}
Если говорить про нормализацию в вакууме, то как будто все хорошо, но у нас же задача сравнить 2 объекта.
Поэтому меня зацепили моменты:
1. Множественный маршалинг: сначала в одну сторону, а потом и в другую (не самая дешевая операция). Почему мы не можем сравнить анмаршаленные объекты?
2. Уже на уровне придирки, но все же. Равенство объектов предлагается находить через рефлексию - для тестов подойдет, но вот для продакшн среды возможно есть более оптимальные решения.
Интересное наблюдение, если вторым запросом поинтересоваться:
Is it straightforward?
То ассистент догадается, что можно обойтись без последнего маршалинга и возможно даже подскажет, что можно вместо map[string]interface{} использовать interface{}.
Вывод
Таким образом, чтобы решить одну задачу с помощью ассистента, у нас появляется 2 задачи, одна из которых - правильно сформулировать запрос или ряд запросов, чтобы получить качественное решение.
Важно помнить:
1. Ассистенты способны решать задачи, но чтобы делать это хорошо, нужен качественный запрос и контекст, формирование которых может быть трудоемким.
2. Ассистент работает поверхностно и прямолинейно с тем контекстом, который вы в него загрузили.
3. Всегда проверяйте предлагаемое решение, особенно если это код. В этом вопросе нужен опыт, поэтому для новичков не рекомендую увлекаться написанием кода с AI.
Если тема будет интересна, то постараюсь собирать подобные истории и делиться тем, как AI помогает в повседневной работе и где он наиболее эффективен.
#ai
🔥3❤1
Мышление письмом
Мне всегда было проще записывать новый материал, рисовать схемки. И пусть они не получаются точными и красивыми, но сам процесс значительно помогает усваивать информацию.
Вот таким у меня получился конспект первой главы System Design Interview (Alex Xu).
И если раньше из этой книги я впитывал как работают Веб-системы, то сейчас интересно подойти к ней системно и спроецировать свои текущие знания на предлагаемый подход к проектированию системы во время интервью.
Как я с этим работаю?
1. Читаю главу.
2. По памяти пытаюсь воспроизвести то, что прочитал.
3. В ходе воспроизведения начинают появляться вопросы, почему именно так устроено, а не иначе - записываю их, чтобы вернуться потом.
4. Отвечаю на все возникшие вопросы.
5. Делаю финальный конспект: корректирую то, что не получилось сразу, сверяясь с источником и особо выделяя ответы на свои вопросы.
Конечно, с таким подходом не получается читать по 365 книг в год, но для меня ценнее брать качеством, а не количеством.
Мне всегда было проще записывать новый материал, рисовать схемки. И пусть они не получаются точными и красивыми, но сам процесс значительно помогает усваивать информацию.
Вот таким у меня получился конспект первой главы System Design Interview (Alex Xu).
И если раньше из этой книги я впитывал как работают Веб-системы, то сейчас интересно подойти к ней системно и спроецировать свои текущие знания на предлагаемый подход к проектированию системы во время интервью.
Как я с этим работаю?
1. Читаю главу.
2. По памяти пытаюсь воспроизвести то, что прочитал.
3. В ходе воспроизведения начинают появляться вопросы, почему именно так устроено, а не иначе - записываю их, чтобы вернуться потом.
4. Отвечаю на все возникшие вопросы.
5. Делаю финальный конспект: корректирую то, что не получилось сразу, сверяясь с источником и особо выделяя ответы на свои вопросы.
Конечно, с таким подходом не получается читать по 365 книг в год, но для меня ценнее брать качеством, а не количеством.
👍10🔥4
Улучшаем код, меняя парадигму
В августе приступил к изучению основ функционального программирования.
ФП притягивало к себе еще с тех пор, когда я писал на C# и стажировался в EPAM.
Тогда я изучал лучшие практики по обработке ошибок в .NET, а мой очень опытный наставник постоянно предупреждал во время код-ревью, что "ему это все не нравится, но так принято..." и будь его воля, то он бы использовал монады и вообще писал бы только на F#.
На мой наивный вопрос "А что такое монады и тоже хочу писать по-взрослому" - получал добрую улыбку со словами, что мне пока рано про такое думать.
Оглядываясь назад, понимаю такой ответ и полностью с ним согласен, но тогда было немного обидно.
Но зачем изучать ФП, если пишешь на нефункциональном языке и работаешь в императивной парадигме?
Основная причина - это открывает целый мир возможностей для более выразительного и чистого кода.
Вот несколько ключевых преимуществ ФП, которые зацепили меня:
1. Чистые функции и отсутствие побочных эффектов
Чистая функция всегда возвращает одинаковый результат для одинаковых входных данных и не изменяет состояние программы. Это делает код более предсказуемым и легко тестируемым.
2. Неизменяемость данных
В функциональном программировании данные неизменяемы. Вместо изменения состояния, функции создают новые значения. Это особенно полезно в многопоточных программах, где изменение состояния может привести к ошибкам.
3. Высокий уровень абстракции
ФП предоставляет мощные инструменты для работы с абстракциями, такие как маппинг, фильтрация и свертка. Эти абстракции упрощают работу с данными и позволяют писать меньше кода.
Хотя мой ежедневный инструмент не является функциональным языком, в нем можно применять некоторые принципы ФП:
В Go функции могут быть присвоены переменным, переданы в другие функции или возвращены в качестве результата. Это дает возможность писать более абстрактный и переиспользуемый код:
Go позволяет использовать чистые функции:
Есть возможность создавать замыкания, которые захватывают переменные из внешнего контекста. Это мощный инструмент для создания функций, которые могут сохранять контекст через замыкания, не используя объекты:
Также можно имитировать функциональные подходы к работе с коллекциями данных, используя стандартные библиотеки. Например, реализовать функции маппинга, фильтрации и свертки через циклы и анонимные функции:
Другая парадигма => другой взгляд на привычные вещи => больше возможностей по взаимодействию с ними.
Вижу, как ФП уже влияет на мой код и делает его лучше. На днях поймал себя на мысли, что интуитивно решил из запутанной функции сделать чистую, что за собой подтянуло другой рефакторинг. В результате получился красивый и модульный фрагмент функциональности, который легко читать и поддерживать.
Замечали ли вы, что использовали подходы функционального программирования, не осознавая этого? А встречались ли вам противники ФП?
В августе приступил к изучению основ функционального программирования.
ФП притягивало к себе еще с тех пор, когда я писал на C# и стажировался в EPAM.
Тогда я изучал лучшие практики по обработке ошибок в .NET, а мой очень опытный наставник постоянно предупреждал во время код-ревью, что "ему это все не нравится, но так принято..." и будь его воля, то он бы использовал монады и вообще писал бы только на F#.
На мой наивный вопрос "А что такое монады и тоже хочу писать по-взрослому" - получал добрую улыбку со словами, что мне пока рано про такое думать.
Оглядываясь назад, понимаю такой ответ и полностью с ним согласен, но тогда было немного обидно.
Но зачем изучать ФП, если пишешь на нефункциональном языке и работаешь в императивной парадигме?
Основная причина - это открывает целый мир возможностей для более выразительного и чистого кода.
Вот несколько ключевых преимуществ ФП, которые зацепили меня:
1. Чистые функции и отсутствие побочных эффектов
Чистая функция всегда возвращает одинаковый результат для одинаковых входных данных и не изменяет состояние программы. Это делает код более предсказуемым и легко тестируемым.
2. Неизменяемость данных
В функциональном программировании данные неизменяемы. Вместо изменения состояния, функции создают новые значения. Это особенно полезно в многопоточных программах, где изменение состояния может привести к ошибкам.
3. Высокий уровень абстракции
ФП предоставляет мощные инструменты для работы с абстракциями, такие как маппинг, фильтрация и свертка. Эти абстракции упрощают работу с данными и позволяют писать меньше кода.
Хотя мой ежедневный инструмент не является функциональным языком, в нем можно применять некоторые принципы ФП:
В Go функции могут быть присвоены переменным, переданы в другие функции или возвращены в качестве результата. Это дает возможность писать более абстрактный и переиспользуемый код:
func main() {
pow := func(x int)int{
return x*x
}
fmt.Println(pow(2)) // 4
}
Go позволяет использовать чистые функции:
func add(a, b int) int {
return a + b
}
Есть возможность создавать замыкания, которые захватывают переменные из внешнего контекста. Это мощный инструмент для создания функций, которые могут сохранять контекст через замыкания, не используя объекты:
func multiplier(factor int) func(int) int {
return func(x int) int {
return x * factor
}
}
func main() {
double := multiplier(2)
fmt.Println(double(5)) // 10
}
Также можно имитировать функциональные подходы к работе с коллекциями данных, используя стандартные библиотеки. Например, реализовать функции маппинга, фильтрации и свертки через циклы и анонимные функции:
func filter(slice []int, condition func(int) bool) []int {
var result []int
for _, v := range slice {
if condition(v) {
result = append(result, v)
}
}
return result
}
func main() {
nums := []int{1, 2, 3, 4, 5}
even := filter(nums, func(n int) bool {
return n%2 == 0
})
fmt.Println(even) // [2 4]
}
Другая парадигма => другой взгляд на привычные вещи => больше возможностей по взаимодействию с ними.
Вижу, как ФП уже влияет на мой код и делает его лучше. На днях поймал себя на мысли, что интуитивно решил из запутанной функции сделать чистую, что за собой подтянуло другой рефакторинг. В результате получился красивый и модульный фрагмент функциональности, который легко читать и поддерживать.
Замечали ли вы, что использовали подходы функционального программирования, не осознавая этого? А встречались ли вам противники ФП?
👍3🔥3
Конец спринта
Мой любимый день, когда можно столько всего успеть в промежутках между встречами:
✅ Завести и продумать задачи на следующий спринт
✅ Задеплоить в пятницу один микросервис
✅ Задеплоить в пятницу другой микросервис
✅ Провести презентацию своей команды на демо
✅ Быть ежедневным дежурным своей вертикали
Как правило, конец спринта за счет большого количества встреч связан с напряжением и стрессом, так как по разным причинам задачи не всегда закрываются вовремя (тут и проблемы с инфраструктурой, и позднее тестирование, и все что угодно).
Но бывают и приятные пятницы, когда в среду уже все проверено, задеплоено на прод, и тебе остается с приятным облегчением наблюдать за выступлением своих коллег на демо.
Катарсис же достигается где-то посередине :)
Мой любимый день, когда можно столько всего успеть в промежутках между встречами:
✅ Завести и продумать задачи на следующий спринт
✅ Задеплоить в пятницу один микросервис
✅ Задеплоить в пятницу другой микросервис
✅ Провести презентацию своей команды на демо
✅ Быть ежедневным дежурным своей вертикали
Как правило, конец спринта за счет большого количества встреч связан с напряжением и стрессом, так как по разным причинам задачи не всегда закрываются вовремя (тут и проблемы с инфраструктурой, и позднее тестирование, и все что угодно).
Но бывают и приятные пятницы, когда в среду уже все проверено, задеплоено на прод, и тебе остается с приятным облегчением наблюдать за выступлением своих коллег на демо.
Катарсис же достигается где-то посередине :)
👍2❤1