Как правильно задавать вопросы?

#softskills
Каждый день на работе нам приходится задавать вопросы.
Мы задаем вопросы, когда мы на старте карьеры. Мы задаем вопросы, когда приходим на новую работу или проект. А как тест инженеры мы постоянно задаем вопросы вроде "А что если эта хреновина в системе вдруг упадет или перезагрузится?".

Почему одни люди с готовностью отвечают на вопросы (даже самые тривиальные) и могут это делать буквально часами. Почему другие - раздражаются на любой вопрос, отсылают вас в Гугл или "сдувать пыль" со старых статей на Confluence?

В своей статье, Julie Evans дает набор техник как сделать ваши вопросы удобнее и лучше для отвечающего. Далее - коротко о статье.

Что такое хороший вопрос? Этот тот вопрос, на который легко ответить.

Какие техники помогают сделать вопросы легче для отвечающего?

1. Озвучьте то, что уже знаете. Озвучьте факт или объясните как вы понимаете концепцию и добавьте "не так ли / я прав?"

2. Задавайте вопросы, где ответ - это факт. В идеальном случае отвечающий должен по вашему вопросу понять, что вы уже знаете и помочь найти то, что вы не знаете. Чем более открытый вопрос вы задаете, тем он более сложный. И ответ на него может занять очень много времени.

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

4. Определите термины которых вы не знаете. Когда вы только приходите на новый проект - вас может "захлестнуть" обилие новых терминов (как технический так и бизнес). Хороший совет - собирать эти термины в своего рода личный вики (словарь) и постепенно искать значения для каждого.

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

6. Решите кого спрашивать.
Задайте себе такие вопросы:
- Сейчас самое время задать вопрос для этого человека?
- Сколько времени займет ответ на ваш вопрос? Может стоит забронировать отдельный митинг с нужным человеком, чем отвлекать его/ее сейчас?
- Обладает ли этот человек нужным уровнем знаний для ответа на вопрос? Не слишком ли он синьйорный для вашего вопроса? Может лучше задать вопрос не лиду, а другому инженеру - и таким образом укрепить его знания в момент ответа.

А как вы задаете вопросы?

Протоколы консенсуса в блокчейне: Proof Of Work

#blockchain #consensus #distributedsystems
Протоколы консенсуса в блокчейне согласно Md Sadek Ferdous и другим авторам научной работы, можно поделить на три большие группы: Proof Of Work, Proof Of Stake и гибридные.

Сегодня мы разберемся, какие бывает протоколы типа Proof Of Work (PoW).

В чем суть протокола?
Суть протокола можно описать так. Узел валидатор собирает транзакции в блок. Для того, чтобы подтвердить блок в сети блокчейна, узел валидатор должен решить некоторую сложную задачу. (Обычно задача заключается в подборе хеш значения специального вида).

За решение задачи валидатор (майнер) получается плату за создание блока и процент от каждой транзакции. Плата за создание блока уменьшается в два раза каждые четыре года.

Сложность задачи в системе постоянно подстраивается - чтобы время на ее решения всегда в среднем занимала определенное количество времени (в Биткоине это 10 минут).

Какие есть различные виды протоколов?
PoW протоколы консенсуса можно поделить на Compute-bound, Memory-Bound и Chained.

Compute-bound Proof Of Work. Алгоритмы этой группы используют вычислительные мощности процессора для решения сложной задачи. Начиналось все с использования обычных CPU, потом продолжили майнить на видеокартах с большим GPU. Как результат эволюции - были придуманы устройства специально для майнинга - ASIC (Application-specific Integrated Circuit).

Примеры алгоритмов консенсуса это Hashcash (предложен для борьбы со спамом) и Nakamoto consensus (используется в Bitcoin).

Memory-Bound Proof Of Work. На заре Биткоина Compute-bound алгоритмы давали возможность майнить любому человеку почти на любом достаточно современном компьютере. Сейчас участвовать в майнинге может далеко не каждый. Для майнинга надо закупаться спец устройствами за большие деньги.

Именно для борьбы с этим ограничением, были придуманы алгоритмы основанные на использовании оперативной памяти. А точнее от ее размера и скорости чтения-записи в нее).

Примеры таких алгоритмов: CRYPTONIGHT, SCRYPT, EQUIHASH, ETHASH/DAGGER (используется в Ethereum), NEOSCRYPT.

Chained Proof Of Work. Суть "связанных" алгоритмов консенсуса заключается в применении нескольких хеш функций подряд. Это повышает стойкость к взлому хеш функций (например с помощью квантовых вычислений). Да и подбирать такие хеши с помощь ASIC устройств очень сложно.
Примерами связанных алгоритмов являются - X11/X13/X15, Lyra2RE, Magnificent 7.

А какие у них есть проблемы у Proof Of Work протоколов консенсуса?

Потребление энергии. Чтобы майнить - нужно перебирать много хешей. А чтобы перебирать много хешей и делать это быстро - нужно много мощных устройств. Много устройств потребляет огромное количество электроэнергии. На майнинг последние годы тратиться столько электричества, сколько хватит некоторым странам на год повседневного использования. А про вред для окружающей среды даже говорить не будем.

Централизация майнинга. Для современного майнинга нужны колоссальные ресурсы. Люди понимают это, потому соединяются в группу "pools" для повышения вероятности получить нужный хеш быстрее. Такие пулы майнеров огромны и уже стремятся к централизации. До недавнего времени, большинство крупных пулов было сосредоточено в Китае.

Tragedy of commons (Трагедия общества). За решение задачи валидатор (майнер) получается плату за создание блока и процент от каждой транзакции. Плата за создание блока уменьшается в два раза каждые четыре года. Эти две платы и есть главными "стимулами", почему люди майнят крипту. В Биткоине технически "зашито", что плата за блок в какой-то момент станет равна нулю.
Трагедией общества в экономической теории называют процесс, когда каждый участник стремится максимизировать только свою прибыль путем истощения ресурса общественного пользования. В контексте Биткоина, когда плата за блок станет равна нулю, валидаторы будут стремиться включить как можно больше транзакции (и получить процент от каждой из них). Со временем, процент платы за транзакцию может стремиться к минимуму. Таким образом стимул майнить - пропадет вообще.

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

В завершение хотел бы поделиться несколькими таблицами, которые описывают различные свойства косенсусов Proof Of Work. (в комментарии).

Советы для собеседующихся на тест инженера (автоматизатора)

#softskills #interview
Мы все ходим собеседования. А некоторые из нас даже их проводят.
Сегодня я поделюсь парой советов о том что делать и что не делать при прохождении собеседования для тестировщика или автоматизатора.

Что делать:

1. Расcказывайте о влиянии на бизнес и процессы, а не о конкретных задачах, которые вы делали. Все пишут юай или апи тесты. И фиксят падающие тесты тоже многие. Продумайте успешные реальные примеры как автоматизация помогает на вашем проекте: дает быстрый фидбек, приносит пользу команде, находит регрессионные проблемы.

2. Честно отвечайте на вопрос: "вы сами писали это решение по автоматизации и поднимали CICD процессы?". Бывают случаи, когда синьором становятся просто за "выслугу лет". То есть инженер пришел на все готовое и поддерживал его лет пять. Такой навык тоже полезен, но так же важно для опытного инженера умение строить автоматизацию с нуля (хотя бы в домашних условиях).

3. Будьте готовы к вопросу - "Почему вы писали именно эти тесты (делали эту работу именно так)?".

4. Не забудьте спросить о текущем состоянии проекта и дальнейших планах на развитие. Этот вопрос со стороны кандидата помогает понять - зачем вообще идти работать в этот конкретный проект? Понимают ли люди зачем тестирование и автоматизация?

5. Будьте готовы к вопросы об архитектуре вашего приложения и фреймворка. Синьор, который вообще не интересуется тем, как работает приложение, происходит деплой, какие виды тестов пишут разные инженеры в компании - это скорее всего или недостаток опыта, или "зашоренность" взглядов и отсутствие стратегического мышления.

Что лучше НЕ делать:

1. Выкладывать ваш фреймворк с предыдущей работы на Github. Встречался несколько раз с таким. Особенно прекрасно выглядят пароли для тестовых или "боевых" баз данных в открытом виде в проперти файлах. Такое лучше вообще не делать.

2. Продолжать интервью, если у вас проблемы со связью. Лучше извиниться и перенести звонок. Или подключиться по запасному каналу связи.

3. Говорить: "Я вообще не знаю, как работает этот код - просто скопировал со StackOverflow". Конечно же, все мы рано или поздно лезем на SO в поисках ответов. Но по крайней мере - разбирайте как код работает, перед тем как сделать Ctrl+C / Ctrl+V.

4. Указывать в вашем резюме все возможные технологии и библиотеки, на которых вы писали от силы полтора теста. Сам так делал в начале своей карьеры:). Просто помните, что по каждой технологии или языку программирования у вас в резюме могут задать вопрос.

Завтра (14.12.21) я буду рассказывать немного о проблемах современного тестирования на митапе Andersen Lab. Приходите) https://www.linkedin.com/posts/andersen-softwaredev_qa-soft-skills-2-in-1-meetup-its-freezing-activity-6867084229293969408-6yYM/

Как правильно отвечать на вопросы?

#softskills
В одной из прошлых заметок мы говорили о том, как правильно задавать вопросы. Но задать вопрос - это лишь пол-дела. Вторая половина - это умение грамотно отвечать на вопросы.

И опять у Julie Evans есть замечательный пост на эту тему. Далее я кратко опишу основные моменты из поста.

Если вопрос не достаточно понятный, задайте уточняющие вопросы.
Обычно новички задают очень непонятные или нечеткие вопросы (или не умеют правильно их задавать). Попробуйте перефразировать и уточнить вопрос. Узнайте более детальную информацию о том, что интересует задающего вопрос. Спросите, что привело их к данному вопросу.

Определите, что они уже знают.
Крайне полезная техника при работе с людьми любого уровня (как с инженерами, так и с менеджерами). Перед тем как отвечать на вопрос, попробуйте узнать, что уже знает задающий. Причем более эффективно будет не просто спросить "Знаешь ли ты технологию (термин) Х?", а "Насколько ты знаком с Х?".

Укажите на документацию.
Если ответ на вопрос действительно можно легко найти в документации - укажите на него. Не просто "посылайте в Гугл-Вики (RTFM)", а хотя бы укажите приблизительно, в каком разделе искать ответ. Этот прием не поможет, если документация безнадежно устарела или таковой у вас на проекте просто нет.

Напишите (обновите) документацию, если нужно.
Вы можете дать ответ и обновить документацию сами. Или, как вариант, поручить обновление документации человеку, который вопрос и задавал.

Поясните, что вы сделали.
Если на вопрос "Как ты сделал это?" вы просто отвечаете "Уже пофиксил, обнови ветку (перезагрузи страницу)" - это не принесет много пользы задающему. Гораздо лучше будет пройтись вместе по этапам инвестигейта/фикса и пояснить что и ПОЧЕМУ вы сделали.

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

Уточните - "Это ответило на твой вопрос?".
Это поможет определить понял ли человек ответ на вопрос. Но нужно быть осторожным. Иногда джуниору проще сказать "Да, я понял", чем признать, что признать что не знает многого из ответа.

Предложите сессию парного программирования (тестирования).
Крайне полезная техника для менторинга или онбординга. Можно даже делать сессии парного программирования вида "девелопер + тест инженер".

Не нужно выглядеть удивленным! Это - самый простой способ понизить самооценку человека и отбить у него желание задавать вопросы (развиваться).
Например: - "Ты не подскажешь, что такое JSON?” - "Как? Ты что, не знаешь даже, что такое JSON?"
Не делайте так. (Вслух я такого никогда не говорил, но в мыслях проскакивало и не раз. Важно понимать, что опыт у всех разный и люди все разные.).

С другой стороны, если вы наняли человека на позицию миддл-синьор, а он снова и снова задает базовые вопросы - подумайте как ему помочь на следующем ревью (или на 1-1). Быть может назначить ментора, отправить на курс или еще что-нибудь.

Очень советую прочесть оригинальный пост. Примеров и пояснений там намного больше.

Видео моего доклада с Andresen Meetup

#video #softskills #career

14 декабря я принял участие в митапе от компании Andresen. Это был мой первый опыт онлайн конференции - когда нужно говорить в камеру, сидя за столом и без людей в аудитории.

Для тех, кто хочет узнать о том, какие я вижу проблемы современного тестирования - мой доклад уже доступен на Youtube.

Ответы на вопросы после доклада

#softskills #hardskills #career
После моего доклада, в чате задали ряд вопросов. На все вопросы онлайн ответить не было возможности, поэтому отвечаю здесь, в виде заметки.

1. Дайте пару советов как быть: проект достаточно расширился. команда QA тоже расширилась. работы много. как быть в курсе всех изменений и не зашиваться?

Если вопрос был о том, чтоб быть в курсе изменений в КУА в компании: проводите еженедельные созвоны с командой. Обсуждайте там изменения в процессах тестирования, уроки преодоления проблем, новые проекты или инструменты. Обычно этот процесс “ведет” QA Manager или QA Lead. Но вы тоже может взять это в свои руки.

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

Что я делаю, чтобы быть в курсе новинок в мире тестирования:

- Слушайте подкасты о тестировании (QA Guild, Test Guild Podcast, The Testing Show, Podlodka, другие).
- Подпишитесь на каналы (Automation Remarks, Burnout SDET , Engineering Readings или твиттер интересующих вас специалистов.
- Используйте агрегатор блог постов по тестированию от Ministry of Testing

2. В итого проще QA перейти в другую компанию на желаемый участок чем перейти внутри компании Почему компания не сохраняет хорошего специалиста ?

На любом этапе вашей профессиональной карьеры только вы ответственны за то, чтобы работать на интересном проекте, получать достойную ЗП и развиваться. Если у вас есть возможность учиться и расти - то менять компанию смысла нет. Если вы чувствуете “потолок” - можно пойти на несколько собеседований и узнать, что делается на рынке труда. Заодно и узнаете, достаточно ли Ваших текущих знаний.
Процесс повышения внутри компании может быть прозрачным, а может быть тернистым и неочевидным. В любом случае, если вы хотите изменить проект, получить новую должность - первый человек с кем можно и нужно пообщаться - это ваш непосредственный начальник.

3. Насколько важна и популярна сертификация ISTQB в странах СНГ?

ISTQB иногда требуют некоторые аутсорс проекты при работе на Германию. (При переезде за рубеж тоже может пригодится). В целом в мире и СНГ особенно - ISTQB сертификат никак не добавит знаний и не заменит вам навыков и опыта.

4. Есть ли явное преимущество у QA с сертификатом ISTQB перед коллегами с таким же опытом без сертификата (в первую очередь при получении работы и в ЗП)?

На позицию трейни сертификат может быть преимуществом при прочих равных. Но тут стоит понимать, что получить сертификат и понять и усвоить информацию из Syllabus - это две большие разницы. Foundation Level вполне можно получить, просто “зазубрил” термины, как в университете на экзамене. Но будет от такой зубрежки толк - это большой вопрос.
На позициях уровня миддл и выше - сертификат ISTQB не играет роли. Играет роль ваш опыт и навыки. (Разве что, сертификаты Advanced Test Manager на позиции менеджера, и то - зависит от компании).

5. Какие виды автоматических тестов бывают?
Очень хорошо описал различные виды тестов (в целом и микросервисной архитектуре) - Мартин Фаулер. Можете посмотреть тут и тут.

6. Как мотивировать себя на изучение и набираться опыта в новых технологиях, если не используешь их в работе на текущем проекте (не знаешь, как применить, платный софт и т.д.)?

Мотивация изучать новое - это глубоко индивидуальная штука. Кого-то мотивируют новые проекты или продукт, помогающий людям. Кого-то - новая должность и больше денег.
Если вы хотите принести больше пользы бизнесу на текущем проекте - то лучше изучать языки программирования и инструменты, которые используются у вас. Тогда и применять их тоже сможете сразу.
Любое изучение новой информации без практики и закрепления - бесполезно. Забудется через 2-3 месяца - и придется учить все заново.
Поэтому если хотите изменить сферу деятельности (перейти в автоматизацию, разработку и тд) - то лучше или заранее определить путь перехода с менеджером и двигаться по нему внутри компании. Или - учить базовые навыки и переходить в другую компанию (возможно с понижением ЗП первое время) - и сразу применять там полученные знания.

7. Если ты какой никакой разработчик, но из за малого опыта и не самого хайпового языка тебя никуда не берут кроме стажировок с мутными перспективами, без оплаты - стоит ли идти в QA?

Тест инженер с хорошими навыки программирования довольно быстро будет прогрессировать в карьере автоматизатора. Ведь и там и там нужно писать грамотный, расширяемый и чистый код. Выучить библиотеки для тестирования - не составит труда.
Другой вопрос - понравится ли вам работа в тест инженерии. Если взять работу автоматизатора - то в 80% случаев это будет добавление новых тестов или исправление старых. И постоянная борьба за “зеленый пайплайн”. Основные “клиенты” вашей работы будут или менеджеры или команда. С пользователями взаимодействовать вы не будете.
Опять таки - есть работа девелоперов, где вы также не будете особо коммуницировать с пользователями (если это не продукт). Будет имплементация нового функционала.
Если смотреть с позиции дальнейшего релокейта - то у девелоперов найти работу зарубежом получается лучше (вариантов выбора больше).
Решайте сами, что вам ближе - создание нового, или проверка старого и разработка инструментов. И то, и другое направление может быть сложным, интересным и хорошо оплачиваться. Плюс никто не мешает переходить из одного направления в другое.

Как получить максимум пользы от разговора с экспертом?

#softskills #learning

Эта неделя получилась более “легкой” в плане тем. Хардкор и технические темы продолжим уже на следующей неделе. А пока я хотел бы поделиться парой интересных моментов, которые я узнал из книги Рона Фридмана “Разгадка гениальности”. Конкретнее - мы поговорим о получении знаний от эксперта. Эта заметка отчасти продолжает темы о вопросах и ответах.

Предположим, вы - начинающий тест инженер и на конференции (или митапе) у вас появилась возможность побеседовать с экспертом в той или иной области. Причем важно получить как можно больше полезного для себя из этого разговора.

Рон Фридман утверждает. что эксперт - не всегда равен хорошему учителю. Любой эксперт, который достаточно глубоко погрузился в предметную область - всегда мыслит абстрактно. У него нет понимания о том, что вы уже знаете, а что нет. 70% знаний эксперт не сможет рассказать вам, потому что не поймет важны ли они для вас или нет.

Так какие же вопросы вы можете задать эксперту, чтобы получить максимум пользы для себя? (Мы не берем в расчет тот случай, когда у вас уже заготовлены крайне конкретные специфические вопросы по инструменту или библиотеке).

Вопросы можно разделить на несколько категорий:

1. О пути - как эксперт достиг успеха (и напомнить ему время, когда он был новичком).
a. “Кого вы читали / смотрели / изучали, чтобы научиться это делать?“
b. “Какие ошибки вы совершили в начале?“
c. “На что вы бы хотели затратить меньше времени, когда учились? Что оказалось неважным?“

2. О процессе - детали работы, подход эксперта к делу, конкретные шаги достижения результатов.
a. “Что вы делаете вначале? Что потом? А после этого?“
b. “Откуда вы берете идеи и стратегии?“
c. “Как вы планируете работу?“
d. “Как вы планируете свой день?“

3. Об открытиях - сравнение с тем, что знаешь сейчас и в начале пути.
a. “Вспомните, что вас больше всего удивило?“
b. “Что бы вы хотели знать, когда начинали?“
c. “Какие неожиданные для вас факторы оказались критически важными для успеха?“

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

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

Протоколы консенсуса в блокчейне: Proof Of Stake

#blockchain #consensus #distributedsystems
Продолжаем разбирать научную работу по протоколам консенсуса в блокчейне.
Хотя Proof Of Work алгоритмы и используются во многих существующих блокчейнах, у них есть ряд серьезных недостатков.
В попытке эти недостатки преодолеть был предложен немного иной подход к генерации и валидации новых блоков в сети. Этот протокол называется - Proof Of Stake (или доказательство ставки, PoS).

В чем суть протокола?
Ключевая идея PoS протокола в том, что те узлы, которые хотят участвовать в генерации нового блока, должны доказать, что располагают определенным количеством монетом на счете. Кроме того, они отдают часть монет в залог (на специальный адрес) как гарантию того, что будут вести себя честно. Если узел будет пробовать систему обмануть - эти монеты будут для него утеряны. Те, кто поставил ставку - принимают участие в “лотерее” на право генерировать блок. Остальные участники сети такого права не имеют. Стимул для генерации блоков сохраняется тем же, что и всегда - это fee с каждой транзакции в блоке.

Какие преимущества протоколов Proof Of Stake:
- Энергоэффективность. Никаких огромных затрат на решение сложных математических задач не нужно.
- Стойкость к централизации. Поскольку задачи решать не нужно, нет нужды покупать дорогое оборудование для майнинга или объединяться в пулы для решения задач.
- Явная экономическая безопасность. Любой, кто попытается взломать систему потеряет свою ставку. Плюс дополнительно, может быть отстранен от создания блоков в будущем.

Какие есть различные виды протоколов?
Главная задача в PoS протоколах - это как выбрать узел, который будет генерировать блок (среди тех, кто сделал ставку). На текущий момент существует несколько подходов к этому - Chained, BFT, Delegated.

Chained PoS. Обычно используется комбинация протоколов PoW и PoS. Узлы, для майнинга по протоколу PoW могут выбраны как случайно, так и в зависимости от других параметров узла (например времени. сколько узел владеет монетами в сети). Примеры - PeerCoin, Casper FFG,

BFT PoS. Узлы для генерации блока выбираются псевдо-случайно, но за них должно проголосовать больше двух третей участников. Примеры - Tendermint, Casper TFG, Ouroboros-BFT

Delegated PoS. Обычные узлы в сети могут делегировать право генерации блока другим узлам в обмен на некоторую плату в будущем. Примеры - EOS, Tron, Tezos, Lisk.

А какие есть проблемы и векторы атак у Proof Of Stake протоколов консенсуса?
1. Если количество узлов валидаторов не достаточно большое, можно легко выполнить атаку 51%.
2. Эффект богатства. Если алгоритм будет основан только лишь на ставке - то принимать участие в генерации новых блоков сможет лишь меньшинство у которого есть средства на счету.
3. Nothing-at-stake (NAS) атака. Во время форка в сети, злоумышленник может попытаться добавить новый блок во все возможные форки для того, чтобы увеличить вероятность добавления своего блока.
4. Bribing (short-range, SR) атака. Злоумышленник может “подкупить” других участников сети, чтобы они добавляли блоки в нужный форк.
5. Long-range (LR) атака. Злоумышленник может попробовать “переписать” историю блокчейна начиная с ранних блоков.
6. Coin-age accumulation (CAC) атака. Злоумышленник ждет пока возраст коинов будет достаточно большой, чтобы сделать форк и провести Double Spend атаку.
7. Pre-computing (PreCom) атака. Если алгоритм недостаточно случайный, злоумышленник может создать несколько блоков (подобрав алгоритм генерации) и потом разом отправить их сеть.
8. Cartel formation (CAF) атака. Возможность картельного сговора между узлами, генерирующими блоки в сети.

Протоколы консенсуса в блокчейне: есть ли жизнь за пределами Proof Of Work и Proof Of Stake?

#blockchain #consensus #distributedsystems
Ранее мы кратко разобрали две большие группы протоколов консенсуса в блокчейне - Proof Of Work и Proof Of Stake.
Но кроме этих двух доминирующих групп, существует множество других идей (как теоретических, так и практических) о том, как сделать протоколы консенсуса лучше (а быть может хуже).

Вот лишь несколько интересных протоколов:

Proof Of Research. Это гибрид между Proof Of Stake и Proof of BOINС (Berkeley Open Infrastructure for Network Computing). BOINC это распределенная вычислительная платформа, ресурсы которой исследователи могут использовать для больших вычислений. Платформа объединяет ресурсы многих вычислительных машин пользователей по всему миру. Исследователям нужно скачать специальный софт на свою машину и принять участие в вычислении некоторой научной задачи. В награду, пользователь получает некоторое количество внутренней валюты - GridCoin.

Proof Of Burn. Суть протокола в том. что для генерации блока надо выслать (”сжечь”) некоторое количество монет на специальный адрес. Взамен - ты получаешь возможность сгенерировать следующий блок в цепочке и получить за это награду.

Proof Of Stake-Velocity. Очень необычный протокол. В некоторых вариантах Proof Of Stake берется в расчет время держания монет на определенном адресе. В PoSV же ключевую роль играет насколько активно совершаются действия с монетами.

Proof Of Cooperation. Право на генерацию нового блока получает специальный узлы - Certified Validating Nodes. Эти узлы выбираются на основе их “активности” в комьюнити.

Proof of Importance. Приоритет на генерацию нового блока отдается тем узлам, которые имеют больше всего входящих и исходящих транзакций.

В комментарии к заметке я приведу несколько интересных таблиц, где исследователи сравнивают протоколы по безопасности, производительности и структуре.

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

Впечатления от книги “Understanding Distributed Systems”

#review #books

В этом году я наконец-то одолел монументальный труд Мартина Клепманна - “Designing Data-Intensive Application”. Но чем больше я погружаюсь в тему распределенных систем и возможных проблем с ними - тем более инетересно разбираться как они работают изнутри. Поэтому я стараюсь читать и другие хорошие книги по теме.

По моим внутренним ощущениям, книга Клепманна будет достаточной сложной для неподготовленного читателя. Вы или будете продираться через массу ссылок на научные работы и гугление терминов или благополучно “забьете” (и оставите книгу до лучших времен).

Но что если я скажу, что есть книга на тему распределенных систем - не такая сложная, как Клепманн, но и не так поверхностно, как многие блоги или ютуб видео?
Такая книга существует. Это - “Understanding Distributed Systems” автора Roberto Vitillo.
Вчера я как раз завершил ее чтение и хочу поделиться впечатлениями.

Что в книге такого хорошего?
Автор рассказывает о том, что такое современные распределенные системы (а они вокруг нас!) и из каких частей они состоят. Концепции и термины грамотно подаются читателю как раз в том порядке, чтобы задуматься “а можно ли сделать этот подход или часть системы еще лучше?”.
Что самое главное - текст практически лишен “воды” - только описание работы системы и практические советы по использованию в реальной жизни.

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

Книга будет интересной, если вы:

- автоматизатор или SDET, которому надоело писать FindBy’и и есть желание наконецто получить целостностное представление о работе современных приложений;
- тест инженер, который хочет понимать как могут “сбоить” даже самые “простые” приложения;
- разработчик уровня джуниор - миддл, который желает выглянуть за пределы кода и паттернов в более реальный мир;
- инженер, который не получил таких фундаментальных знаний в университете (по какойто причине) и хочет заполнить пробелы в знаниях;
- готовитесь к system design interview;
- читатель, который не осилил Клепманна сразу, но хочет вернуться к нему потом);

Книга не принесет пользы, если вы:

- матерый инженер или исследователь распределенных систем и прочли Клепманна и много других научных работ по теме.
- инженер, который хочет глубоко и методичного погружения в тему. Для этого есть другие книги.

Если у Клепманна было 10 из 10, то тут могу поставить 8 из 10. По простоте и доступности изложения напомнила мне Leading Quality.

Заблуждения о распределенных системах и зачем это нужно тест инженеру?

#distributedsystems
Что такое распределенная система?
Простыми словами, распределенная система - это система, которая состоит из множества узлов (например компьютеров, процессов, устройств), которые общаются по сети и вместе выполняют какую-то задачу.

Лесли Лэмпорт, известный исследователь и автор научных работ, дал такое описание:
“Распределенная система - это система, в которой отказ одного узла, о существовании которого вы даже не догадывались, выведет из строя или заблокирует всю систему.”

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

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

Питер Дойч (и ряд других инженеров) из компании Sun Microsystems еще в 90х годах сформировали список этих предположений. В интернетах их можно найти по запросу “8 fallacies of distributed computing”.

Восемь заблуждений о распределенных системах:
Сеть надежна. В реальности - пакеты в сети могут “теряться”, сервисы могут останавливаться и бесконечно ждать ответа.
Задержка в сети равна нулю. Задержка в сети будет всегда - как минимум она ограничена скоростью света. То есть невозможно мгновенно передать пакет по сети с одной точки Земли в другую.
Пропускная способность бесконечна. Пропускная способность мало того, что ограничена, так еще и может быть отличной для разных узлов.
Сеть защищена. По факту, любые сообщения, отправленные по сети могут быть перехвачены злоумышленниками. Или узлы сети могут быть атакованы или просто заблокированы.
Топология сети не меняется.
В сети всегда есть один администратор. Узлами и подсетями могут управлять куча разных компаний с разными политиками безопасности.
Транспортные расходы равны нулю.
Сеть однородна. В реальном мире узлы в сети могут быть совершенно разными, с различными характеристиками.

Зачем МНЕ знать о распределенных системах - я всего лишь тестер?
Если вы тестируете приложение, которое немного больше, чем пару простых скриптов, есть ненулевая вероятность, что вы так или иначе разрабатываете (или используете) распределенные системы.

- У вашего приложения есть база данных? Она вполне может быть распределенной.
- У вас на бекенде микросервисы? Это тоже по сути распределенная система.
- Трафик на входе регулируется с помощью балансировщиков нагрузки? Они тоже могут быть распределенными.
- Компоненты обмениваются сообщениями через месседжинг (например Apache Kafka)? И это тоже может быть распределенным.
- Вы хостите несколько дата центров в разных частях света, чтобы быстрее отдавать ответы пользователям? Это тоже распределенная часть.

По сути, почти любое большое современное приложение - это распределенная система. И состоит из ряда меньших систем).

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

 - как эти системы работают? (уровень easy)
 - как эти системы могут выйти из строя? (уровень medium)
 - как можно уменьшить риск выхода из строя? (уровень hard)

Ошибка композиции или зачем вообще нужно end-to-end тестирование

#testing #distributedsystems
Тестируя распределенные системы (или любые большие сложные системы, которые состоят из распределенных частей), всегда есть риск столкнуться с таким феноменом, который известен как “ошибка композиции”.
В философии, это выражение, когда на целое переносят свойства отдельных частей. Такой перенос является в большинстве случаев неправильным.

Например:
- “Атомы бесцветны. Роза состоит из атомов. Следовательно, роза - бесцветна.”
- “Индивиды ведут себя рационально. Следовательно и общество, как сочетание индивидов ведет себя рационально”.
- “Каждая часть механизма весит немного. Значит и весь механизм весит немного.”
- “Если бегун бежит быстрее, то он может выиграть гонку. Следовательно. если все бегуны будут бежать быстрее - все одержат победу.”

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

Грядет большой релиз, поэтому разработчики хотят помочь с тестированием. Они пишут уйму юнит тестов для своего кода. Добавляют контрактные тесты. Тестируют каждый микросервис “от и до” в изоляции.
Каждый сервис по отдельности работает корректно и стабильно. (Например code coverage равен 100%. Или облачный провайдер дает SLA 99.999%).

Эти данные могут привести к выводу, что и вся система целиком будет работать корректно и правильно.
В реальности, при деплое этой сотни идеально работающих микросервисов может возникнуть множество ошибок интеграции (репликации данных, каскадных ошибок). Вся система или огромные ее части могут быть полностью в нерабочем состоянии.

Именно поэтому важно проводить тестирование как и отдельно взятых компонентов, так и всей системы целиком. Все виды тестирования важны и нужны.

Отдельно хочу упомянуть одну интересную форму ошибки композиции - ошибку линейности.
Пример такой ошибки хорошо описан в книге “Perfect software and other Illusions about testing”. Там тестировщик проверил поведение системы с одним пользователем и получил время ответа в десять миллисекунд. Проверил тот же тест для двух пользователей - и получил время двадцать миллисекунд. Следовательно, он сделал ошибочный вывод, что для 100 пользователей, время отклика будет равно 10 мс * 100 = 1 с.
Но в реальных больших системах разумеется такой линейной зависимости практически никогда нет.

Как еще один пример ошибки линейности, (или того, что 2 + 2 не всегда равно 4), автор книги приводит обогащение урана-235. Если мы добавим к десяти килограммам Урана-235 еще десять - мы получим 20 кг. Но если мы сделаем так несколько раз - в результате мы получим ядерный взрыв.

Немного об ошибке композиции еще описывается в этом посте.

Простое тестирование может предотвратить наиболее критические ошибки в распределенных системах

#testing #distributedsystems #paper
В своей научной работе “Simple Testing Can Prevent Most Critical Failures” авторы дают очень хороший обзор ошибок, которые могут происходить в реальных распределенных системах.
В пример приводятся такие системы, как Cassandra, HBase, HDFS, MapReduce, и Redis. Исходный код и багтрекинговые системы этих систем были в открытом доступе на момент публикации этой работы.

Вот топ пять интересных результатов исследований:
1. Для большинства отказов системы требуется больше одного входящего ивента, но не более трех. 50% всех ошибок воспроизводятся при коммуникации двух узлов. Это означает, что для симуляции распределенных систем необязательно “копировать” весь продакшн с сотнями и тысячами узлов. Нужно всего-лишь два-три узла.

2. 74% отказов - детерминированы. Это означает, что есть возможность получить четкую последовательность событий в системе, которая приводит к ошибке.

3. 76% отказов выводят логи (в том числе и входные параметры). Благодаря логам есть возможность быстрее обнаружить проблемы.

4. Юнит тесты могут воспроизвести 77% ошибок в продакшене! Интеграционное и end-to-end тестирование могли бы отловить такие ошибки, но гораздо быстрее и эффективнее это делать на юнит уровне.

5. 92% ошибок происходят из-за неправильной обработки ошибок (разной степени критичности). Многие обработчики ошибок были слишком высокоуровневыми. В некоторых случаях, они даже содержали комментарии вроде TODO или FIXME :). То есть потенциально, такие слабые места в коде могут (и должны) быть проанализированы внешними инструментами анализа кода и другими инженерами на код ревью.

Что может пойти не так при коммуникации в распределенной системе? (Часть 1).

#testing #distributedsystems
Под коммуникацией будем понимать обмен сообщениями между двумя узлами (Node 1 и Node 2).
Самый яркий и практический пример - это когда клиент делает обычный HTTP запрос к серверу.

Что может произойти при коммуникации?

1. Node 1 успешно отправит запрос и получит ответ от Node 2.

2. Node 1 отправит запрос и он по какой то причине не дойдет до Node 2.

3. Node 1 отправит запрос, Node 2 его получит и при попытке обработать - станет недоступен. (А ведь под капотом, Node 2 может также делать запросы к другим узлам!)

4. Node 1 отправит запрос, Node 2 обработает и вернет ответ, но Node 1 ответа не получит.

Что может пойти не так при коммуникации в распределенной системе? (Часть 2).

#testing #distributedsystems
Если Node 1 не получит ответа от Node 2, то не сможет понять в чем причина проблемы. Это могут быть проблемы в сети и потеря сообщения, могут быть проблемы на Node 2 или просто медленный канал связи.

Очевидно, чтобы Node 1 не ждал ответа вечно, можно применить механизм ожиданий (Timeout) ответа. Вышли за пределы таймаута - Node 1 сгенерировал ошибку коммуникации.

Но какой таймаут должен быть?
Если поставить слишком маленький таймаут, Node 1 может ошибочно решить, что Node 2 недоступен. С другой стороны - если таймаут слишком велик - время ожидания может здорово повлиять на производительность системы.

Как альтернативу таймаутам, можно использовать механизмы ping и heartbeat.

- Ping. Node 1 может время от времени “пинговать” Node 2 и проверить “жив” ли узел. Даже если в какой-то момент узел не ответит, Node 1 может продолжать слать такие запросы в надежде, что Node 2 рано или поздно будет доступен.

- Heartbeat. Node 2 может сам посылать специальные сообщения всем узлам, с которыми коммуницирует. Таким образом, он уведомляет сеть, что находится в рабочем состоянии. Если Node 1 не получает heartbeat сообщения от Node 2, то помечает этот узел как недоступный.

Оба механизма очень часто используются в распределенных системах. Например для коммуникации и синхронизации микросервисов на бекенде.

Обзор курса - “Blockchain Scalability and its Foundations in Distributed Systems”

#review #blockchain #course
Кроме заметок на интересные технические темы, я хотел бы также делиться интересными курсами, которые прохожу на разных ресурсах.
Быть может вы тоже захотите их пройти. Или не захотите. Anyway.

Совсем недавно я прошел “Blockchain Scalability and its Foundations in Distributed Systems” на Coursera. Ниже я поделюсь своими впечатлениями от прохождения.

Что в курсе хорошего?
- довольно подробно рассказывается о том почему важен консенсус (особенно в блокчейне)
- описывается множество алгоритмов работы консенсусов в системах разной сложности (от гипотетических систем с отсутствием отказов до систем с византийскими сбоями)
- каждый алгоритм оценивается по трем разным параметрам (message complexity, communication complexity, time complexity)
- приводятся примеры атак на блокчейн системы
- обсуждается пример того, как можно улучшить производительность существующих блокчейн систем с помощью протокола DBFT на примере Red Belly Blockchain
- дается просто огромный список научных работ на дополнительную проработку

Что в курсе не очень хорошо?
- курс не для новичков: автор буквально с первых слайдов рассказывает про консенсус, распределенные системы и как работает блокчейн
- в курсе приводится оценка сложности алгоритмов консенсуса в О нотации (поэтому надо знать, что это такое)
- курс показался немного скомканным на последней неделе: слишком много новой информации и концепций приводится буквально за несколько минут. Подобный объем информации вначале курса подается за 2-3 недели
- курс рассчитан на пять недель, но по факту, его можно пройти намного раньше - максимум за неделю
- очень не хватало практической составляющей - весь курс это как набор лекций.

Моя оценка:
- полезность: 6 / 10
- сложность: 3 / 10

Итоги 2021

2021 год подошел к концу. Год, в котором коронавирус все еще не сдает позиций, мир все еще пребывает в режиме Circuit Breaker, а работа и жизнь все больше уходят в онлайн, на удаленку.
Пора подводить итоги уходящего года.

Что было интересного:

Смена работы. Этой весной я присоединился к компании IOHK. Опыт был очень волнительный: переход на полную удаленку, “возвращение” от Software Engineer позиции к Software Engineer In Test, команда с разных уголков нашей планеты.

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

Обучение. Погрузился (и еще продолжаю) в темы блокчейна, Scala, AWS, релиз инжиниринга. Прошел довольно много курсов (на Курсере, Юдеми и просто на Ютубе)

Новый опыт. Купил себе микрофон и даже записал ряд туториалов для нашего продукта (было сложно, но мне понравилось).

Книги. Прочел за год около 40 книг (как по тематике IT, так и художественных и научно-популярных). О лучших технических я уже писал.

Блог. В третий раз “реанимировал” свой блог и умудрился написать целых 20 статей! (А это почти столько же, сколько я написал за все предыдущие четыре года). Спустя несколько месяцев, я столкнулся с проблемой написания статей на английском языке (писать сразу на другом языке тексты среднего-большого размера оказалось для меня непростым занятием)

Телеграм канал. В конце ноября я завел Телеграмм канал на русском, посвященный темам тестирования и распределенных систем. С помощью заметок в канале я делюсь интересными вещами, о которых узнаю сам. Заметки помогают мне писать более структурированно. К тому же, заметки потом “превращаются” в полноценные статьи в блоге.
Удивительно, но на конец декабря, меня уже читает 260 человек! Спасибо вам, дорогие подписчики. Это потрясающе и мотивирует писать дальше.

Доклады. В этом году я практически не выступал публично. В начале года я еще раз рассказал о контрактах, а в конце года - о проблемах в тестировании. Последний доклад “зрел” довольно давно. Основным мотиватором стал для меня доклад Сергея Пирогова о разделении тестировщиков на “ручных” и “автоматизаторов”.

Профессиональный интерес. Нашел наконец-то темы, в которые мне интересно “копать” - это распределенные системы и их качество. Сюда входит в том числе блокчейн.

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

Плюсы и минусы контрактного тестирования

#testing #contracts #microservices
Всех с прошедшими новогодними и грядущими рождественскими праздниками!

О контрактных тестах я много рассказывал на конференциях (1 и 2), а также в своем блоге.
Сегодня я хотел бы поговорить о реальных плюсах и минусах контрактных тестов для приложений с микросервисной архитектурой.

Плюсы:
- End-to-end тестов может стать меньше. Сами контрактные тесты конечно не заменят end-to-end, а вот комбинация unit + component + contract - вполне может заменить часть больших и громоздких тестов через UI. На end-to-end уровне можно оставить только самые важные юзер сценарии.

- Breaking change будет сделать очень трудно. Правильно выстроенный процесс работы с контрактными тестами минимизирует вероятность появления любых изменений ломающих взаимодействие между сервисами. Разработчик банально не сможет “пропихнуть” свое изменение по-быстрому - т.к. ему нужно собрать аппрувы от всех (или многих) сервисов консьюмеров.

- Тест инженеры будут рады. Тест инженеры смогут немного отвлечься от бесконечного фикса UI и API тестов и попробовать что-то новое и технически сложное. Мотивация и уровень инженеров растет.(При условии, что они хотят развиваться технически, конечно).

Минусы (они же сложности):
- Сложность настройки инструментов. Для начального Proof Of Concept для одного-двух сервисов “в вакууме” настроить инструмент никаких проблем нет. Но если вы хотите масштабировать инструменты и интегрировать их в CICD процессы - это требует немало усилий.

- Коммуникации и поддержка менеджмента. Контрактное тестирование - это на 95 процентов про коммуникации и процессы, а на 5 процентов - собственно написание тестов. Если у вас нет отличной поддержки от менеджмента, или команды постоянно винят друг друга в ошибках в продакшене и не хотят общаться и искать компромиссы - контрактные тесты внедрить не получиться от слова совсем. Все закончится на этапе - “М-м-м, прикольная штука - но у нас не сработает”. Или еще хуже “Прикольная штука - давай ты внедришь ее сам ВЕЗДЕ. А там посмотрим на результаты”.

- Тренинги. Разработчикам нужно будет проводить тренинги по использованию библиотек, а также по измененным процессам. Если вы планируете для написания контрактных тестов привлекать также и тестировщиков - то нужно дополнительно обучить их более углубленным знаниям программирования. Это невероятно, но при использовании Spring Cloud Contract библиотеки, нужно знать базу Spring Boot. (а это уже немного сложнее, чем просто пилить GET POST запросы на Rest Assured).

- Покрытие контрактными тестами legacy сервисов. Чтобы в полной мере ощутить полезность контрактных тестов, кроме новых эндпоинтов, нужно покрывать контрактами и старые. Поэтому надо или заложить это время в спринты для разработчика, или делать это усилиями выделенной команды автоматизации. Что тоже занимает время.

- Контрактные тесты не спасут, если у вас все печально с unit и component тестами. Они работают в комбинации - и каждый из видов тестов дает свою долю уверенности в покрытии.