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

#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 тестами. Они работают в комбинации - и каждый из видов тестов дает свою долю уверенности в покрытии.

"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson

#testing #distributedsystems #video
Слушаю тут прекрасный курс по распределенным отказоустойчивым системам. В одной из лекций рекомендовали посмотреть видео про тестирование распределенных систем в FoundationDB.

Для справки, FoundationDB - это оупен-сорсная NoSQL база данных с ACID транзакциями уровня Serializable. Позволяет хранить отсортированные пары ключ-значение в виде произвольных последовательностей байтов.

Доклад конечно слегка старый (2014 год - еще до того, как их купила Apple), но все-таки было любопытно увидеть как подходят к вопросу тестирования в больших распределенных база данных.

Несколько ключевых мыслей из доклада:
- Багов в распределенных БД очень много. (Неожиданно!)

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

- Ребята заморочились и до того, как писать код своей БД, они написали симуляцию своей базы данных и на ней гоняли огромное количество тестов. И даже написать свое расширение для C++ под названием Flow. Это дополнение позволяло писать псевдо-многопоточный код, который бы выполнялся в рамках одного реального физического потока.

- Зачем строить свою симуляцию? Для того, чтобы хоть какой-то из компонентов был детерминирован и его можно было адекватно тестировать. Вся коммуникация с “внешним” миром была под контролем инженеров. Как результат - они могли исследовать разные сбои и смотреть как их система будет на них реагировать.

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

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

- Интересно, что они даже нашли пару багов в third-party системах (ZooKeeper и Linux).

Очень рекомендую этот доклад к просмотру. Даже если у вас (как и у меня) C++ - это далеко не сильная сторона. Его тут немного. Что важнее - идеи и размышления докладчика.
В дополнение, немного о процессе тестирования описано и на странице самого проекта.

Подходы к верификации распределенных систем (by Caitie McCaffrey)

#distributedsystems #testing

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

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

1. Статическая верификация системы:

- Formal Verification. Подход, при котором на специальном языке (TLA+, Coq) описывается система и ее параметры. Кроме того, формируются ряд утверждений о корректности работы системы. Потом это описание проверяется автоматическими инструментами анализа.
По сути, это математическое доказательство того, что ваша система (на глобальном уровне) будет работать так, как предполагается. Такой подход дал хорошие результаты при проектировании AWS сервисов, таких как S3.
Главным минусом такого инструмента является то, что для написания таких математических доказательств нужен определенный опыт и знания. (Такое не нагуглишь по-быстрому).

- Model Checking. Тоже формальный метод, который проверяет граф состояний системы и позволяет найти проблемные места. Но т.к. состояний в больших системах может быть очень большое количество - то такой метод перебора может занимать много времени. Автор статьи приводит пару примеров инструментов (Spin, MaceMC, MoDIST), но они существуют в виде приложений к научным работам. Поэтому я не знаю насколько они применимы в реальной жизни.

2. Динамическая верификация системы:

- Monitoring. По сути это сочетание трейсинга, мониторинга и алертов в продакшн системах. Например в бекенде с сотнями микросервисов, очень удобно отследить весь путь одного запроса через множество сервисов. И на каком этапе этот запрос сбоит. Из инструментов самые известные тут это Dapper и Zipkin.

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

- Unit and Integration Tests. Куда уж без старых добрых тестов. О важности таких тестов я недавно писал в анализе научной работы об ошибках в распределенных системах.

3. Техники внедрения неисправностей.

- Random Model Checkers. В некоторых случаях полезно применить разные библиотеки по property-based тестирования. Например QuickCheck или ScalaCheck. В таких инструментах вместо зафиксированных инпутов, вы просто описываете некое множество вариантов значений. А дальше библиотека при каждом запуске тестов, генерирует новые инпуты и проверяет, что система работает корректно и с ними.

- Netflix Simian Army. Тут целый набор полезных инструментов для симуляции отказов в как отдельных узлов, так и целых кластеров или даже availability zones в облаках.

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

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

Как я читаю книги

#books #learning
В одном из комментариев под постом с итогами 2021 года, меня спросили, как я успел прочесть 40 книг (по работе и художественных). В сегодняшней легкой заметке я расскажу пару моментов, которые помогают лично мне читать книги (и черпать нечто полезное из них).

Выбирайте книги в соответствии с целями
Все книги по всем интересным темам прочесть невозможно. Можно, конечно, как Билл Гейтс устраивать себе “Think Week” или даже “Think Month”. (Уехать в одиночку, без гаджетов, в уединенный домик на природе и читать :)).

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

Чередуйте профессиональную литературу и книги “для души”
Такой подход помогает “разгружать” мозги после тяжелой технической литературы. Фантазию отлично стимулирует научная фантастика, фэнтези, даже хороший качественный детектив.
Научно-популярные книги помогают расширить кругозор - ведь жизнь, кроме IT, существует.

Составьте план на день, неделю и включите чтение в каждодневную рутину
Иногда дел столько, что спасает только включение чтения отдельной задачей в список дел на день. Это может быть даже 15-30 минут в день. Важно только, чтобы у Вас было "мыслетопливо", чтобы обработать знания из книги.

Читайте профессиональную литературу с заметками
Только с 2021 года я начал не просто читать книги, статьи и проходить курсы, но и записывать краткий конспект по ним. Фиксировать свои мысли “на бумаге” здорово помогает для лучшего понимания материала. Плюс к таким заметкам удобно вернуться, если нужно быстро вспомнить материал.

Плюс, можно организовать учет книг, которые ты прочел, ставить свои оценки.
Мне тут помогает такой сервис, как Notion.

Находите время для чтения
Безусловно свободного время у каждого очень мало. Хочется успеть все и даже больше. Не буду тут “открывать Америку” и скажу просто, что важно делать выбор в зависимости от Ваших приоритетов. Плюс - есть ли у вас
Еще при чтении поможет отключать гаджеты и читать строго отведенное время. Или просто просыпаться немного раньше и читать. (Мне помогает).

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

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

Бросайте книгу если она читается трудно или оказалась неинтересной вам.
То что книга включена в кучу must-read списков вовсе не означает, что она подойдет лично Вам в данный момент Вашей карьеры. Кабанчика я начинал читать и бросал несколько раз. И только спустя несколько лет я вернулся к ней и с огромным удовольствием ее прочел. То же касается в моей случае первой “Дюны” Герберта.

А иногда книга может быть просто отвратительной, полной "воды" или переливания из пустого в порожнее. Или Вы, например, уже “выросли” из книг категории “туториал с официального сайта в формате книги”. Такие книги лучше бросать и не тратить на них времени.

А как читаете книги вы?

[Для тест инженеров] Пару интересных митапов января

#meetup
За окном январь, новогодние праздники почти прошли - поэтому пора учиться и социализироваться.
Я хотел бы рассказать о паре интересных митапов для тест инженеров, которые пройдут уже совсем скоро.

- 15.01.22 будет проходить AD Software Testing Online Meetup #8. Anton Yakutovich в очередной раз собирает СДЕТов и им сочувствующих для обсуждения интересных технических тем. На этом митапе я буду говорить о проблемах современного тестирования, а Sergey Shaikin расскажет об эффективной работе с логами в Кибане. Доклады будут на английском.

- В тот же день (15.01.22) можно сходить на митап от UniEd - ''Selenide - просто пишем тесты''. Это ивент для совсем джуниоров в автоматизации и тех, кто хочет ими стать.

- 26.01.22 для начинающих и продолжающих автоматизаторов можно заглянуть на воркшоп от Артура Шевченко, посвященный репортингу с Allure в GitLab’e.

А какие митапы в январе хотите посетить вы?

Что такое симметричное шифрование (простыми словами)?

#security #blockchain #cryptography

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

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

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

Самый простой симметричный шифр?
Шифр Цезаря - в котором каждая буква исходного сообщения заменяется на букву алфавита с каким-то сдвигом относительно начала. Например буква A со сдвигом 3 будет превращена в букву D. (И да, этот шифр назван в честь Гая Юлия Цезаря, потому что активно применялся еще теми самыми римлянами для шифрования писем). Но такой шифр крайне просто взломать.

Что же в современном мире?
В современном мире конечно буквы в алфавите не двигают. Обычно используют побитовую операцию XOR (исключающее или) и огромное количество битовых преобразований, перемешиваний, подстановок на протяжении многих раундов.
Что такое XOR (^)? Коротко: если биты A и B разные, то A ^ B = 0. Иначе A ^ B = 1.
Почему XOR? Например - 123 ^ 45 = 86. (где пусть 123 - исходный текст, а 45 - ключ). Тогда 86 это зашифрованный текст. А если сделать вот так: 86 ^ 45 = 123 (исходный текст!). МАГИЯ!

Примеры алгоритмов шифрования?
AES, 3DES, RC2, Blowfish, RC4 и множество других.

Где используется шифрование?
Для шифрования данных пользователя и его карт при банковских транзакциях. Для шифрования данных на диске.
Комбинации симметричного и асимметричного шифрования используют в SSL/TLS, в защищенных мессенджерах.

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

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

Для желающих узнать чуть больше, есть классные видео объяснения симметричных шифров и даже AES.
А для тех, кто хочет погрузиться в захватывающую историю шифров, взломов - крайне рекомендую "Книгу Шифров".

База знаний по тестированию блокчейна

#blockchain #testing

Не так давно я коротко рассказал о том, что нужно знать для тестирования блокчейн систем.

Хочу сегодня поделиться более подробной картой знаний. Надеюсь она поможет вам немного лучше представить объём знаний и темы. В заметках на этом канале я планирую постепенно рассказать о большинстве пунктов. Хотя бы на уровне понимания “как это работает” (а самое главное - как это тестировать).

Дополнительно, я веду подборку статей, видео и научных работ по тестированию блокчейна (и постепенно их читаю).

Давайте вместе узнавать что такое блокчейн (и другие распределенные) системы и где они обитают 🙂

Как быть более эффективным тест инженером

#softskills #career
Многие тестировщики (особенно уровня миддл. синьор) часто жалуются, что ИТ индустрия “сломана”, “мы такие крутые спецы, делаем крутые штуки - а злые менеджеры не повышают”, “не повышают - пойду трясти офферы” и прочее. Сам был таким когда-то, чего скрывать.

Вместо того, чтобы трясти оффером и быстро уходить из компании, можно понять, как увеличить бизнес ценность и влияние своей работы на бизнес.
В начале месяца, Cindy Sridharan написала просто отличную статью на эту тему “know how your org works (or how to become a more effective engineer)”.

Вот кратко тезисы из статьи:
1. Важно понимать, что премии, повышения дают не просто “за крутые штуки”, а за то, что имело большую ценность для бизнеса.

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

3. Изучать что-либо легче, если знаешь что учить, как учить и когда информация неизменна (например технические концепции).

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

5. Очень помогает знать явные и неявные иерархии в компании. В неявных иерархиях, могут быть менеджеры или опытные инженеры, убедить которых нужно в первую очередь, чтобы ваши предложения приняли.

6. Также помогает изучить прошлые успешные и неуспешные кейсы внедрения улучшений в компании. Сделайте выводы, что получилось правильно и почему.

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

8. Изучайте, какого рода культура в вашей организации - “top-down” или “bottom-up”.

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

Очень рекомендую прочесть оригинальный пост, особенно если вы лид, менеджер или просто синьорный инженер.
Подобные идеи кстати описываются в книге Effective Engineer.

Интересные каналы и ресурсы для изучения нового (или закрытия “пробелов” в знаниях)

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

Работая в IT так или иначе надо постоянно обучаться. Это может быть новый инструмент, новый продукт, новый язык программирования.
Сайтов с курсами (платными и бесплатными) существует огромное множество. Все о них слышали, знают, используют. Какие-то ресурсы хороши, какие-то - сомнительного качества. Но кроме платных и бесплатных ресурсов для обучения конкретным инструментам, есть еще интересные каналы на Youtube. Сегодня я хочу поделиться небольшой подборкой. Может вам будет что-то из этого полезно.

Интересные ресурсы (и да, они на английском):

- 5 Levels of Difficulty (плейлист от Wired). Приглашенный эксперт раскрывает выбранную концепцию на пяти различных уровнях сложности: дошкольник, школьник, студент, выпускник ВУЗА, взрослый). Помимо интересного объяснения, дает множество идей о том, как одну и ту же тему можно донести в зависимости от количества знаний у человека.

- Explain me like I’m 5. Это целый сабреддит с такими вопросами и ответами (по сути - обьяснение сложного - простыми словами). Можно даже гуглить отдельные вопросы с префиксом - ELI5. Например - ELI5: Why are the polar ice caps melting? Кроме того, Фейсбук в таком формате говорит о своих оупен-сорс библиотеках.

- Khan Academy (и на русском). Просто отличный канал, в котором можно найти уроки не только по компьютерным наукам, но и другим предметам школьной программы. Можно посмотреть, как учат математику в школах в США (и даже разобраться в темах и предметах, которые в школе преподавали плохо). Видео от автора реально используют как материал в школах.

- Computerphile. Довольно хардкорный канал, в котором подробно разбирают множество терминов и концепций из Computer Science.

- Internet-class. Короткие видео по различным вещам из компьютерных технологий. Правда новых видео автор уже к сожалению не выпускает.

Я намеренно не указывал никаких каналов посвященных тестированию или определенным языкам программирования - т.к. их вы и так, я думаю, видели немало.

А какие у вас любимые интересные ресурсы для изучения нового?

Ура! Нас уже 300!
Спасибо, что читаете. И спасибо за комментарии и фидбеки.