Как проверить систему, не запуская её (Гейзенбаг 2017)

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Андрей Сатарин, @asatarin Как проверить систему, не запуская её

Slide 3

Slide 3 text

Вы отвечаете за uptime в вашем проекте?

Slide 4

Slide 4 text

Да — вы в правильном месте Нет — еще можно уйти

Slide 5

Slide 5 text

Проблема

Slide 6

Slide 6 text

Сервис 6 Клиент Клиент Клиент Клиент

Slide 7

Slide 7 text

Как не зафакапить наш сервис?

Slide 8

Slide 8 text

〉модульные тесты 〉функциональные тесты 〉тесты производительности 〉еще немного тестов 〉и еще тесты Как не зафакапить наш сервис? 8   Functionality  Usability  Reliability  Performance  Supportability  + 

Slide 9

Slide 9 text

9 Сервис = код

Slide 10

Slide 10 text

10 Сервис = код + конфигурация

Slide 11

Slide 11 text

11 Сервис = код + конфигурация

Slide 12

Slide 12 text

Как (не) убить сервис конфигурацией?

Slide 13

Slide 13 text

Пример 1 Одноклассники 2013

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

«Однажды вечером система мониторинга зафиксировала незначительную проблему с одним из серверов. Для её устранения нужно было поправить шаблон конфигурации.» Три дня в Одноклассниках — начало 15

Slide 16

Slide 16 text

«Но дежурный администратор правил файл шаблона в другом редакторе, который поместил этот символ в конец файла» Три дня в Одноклассниках — кульминация 16

Slide 17

Slide 17 text

«В Одноклассниках, как и во многих других проектах, применяется инцидент-менеджмент. То есть все нештатные ситуации фиксируются и делятся по категориям: 〉баг в нашем коде, 〉ошибки конфигурации, …» Три дня в Одноклассниках — развязка 17

Slide 18

Slide 18 text

Пример 2 Google Chubby

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

«By their very nature, fault-tolerant systems try to mask problems» Chubby — обычная работа 20 Для консенсуса нужно большинство — 3 из 5 нод

Slide 21

Slide 21 text

«By their very nature, fault-tolerant systems try to mask problems» Chubby — работа со сбоями 21 Для консенсуса нужно большинство — 3 из 5 нод

Slide 22

Slide 22 text

«We once started a system with five replicas, but misspelled the name of one of the replicas in the initial group» Chubby — ошибка в конфигурации 22 Для консенсуса нужно большинство — 3 из 5 нод

Slide 23

Slide 23 text

«We once started a system with five replicas, but misspelled the name of one of the replicas in the initial group» Chubby — ошибка в конфигурации + сбои 23 Невозможно собрать большинство из 5 нод

Slide 24

Slide 24 text

〉Не могут быть найдены модульными/функциональными/и т.д. тестами 〉Могут очень дорого стоить 〉Могут быть незаметны долгое время 〉Им уделяют мало внимания Вывод: ошибки конфигурации 24

Slide 25

Slide 25 text

Код vs конфигурация 25 Код Конфигурация Java/C++/Python/etc Protobuf/XML/JSON/YAML/etc Строгий синтаксис Строгий синтаксис Строгая семантика Семантика не специфицирована Ревью/тесты/еще тесты/и т.д. ???

Slide 26

Slide 26 text

Что делать? — Мы очень внимательно проверим конфигурацию!

Slide 27

Slide 27 text

〉Хранится в 18 protobuf файлах 〉Спецификация этих файлов — 400 строк кода 〉Множество внутренних связей 〉Больше нод — больше конфигурация Конфигурация «Проект К» 27 Нод в кластере Строк конфигурации 8 нод 700+ 32 ноды 1600+ 300 нод 10000+

Slide 28

Slide 28 text

Что делать?

Slide 29

Slide 29 text

Теория

Slide 30

Slide 30 text

https://twitter.com/allspaw/status/922494066620796928 30

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

«Our study shows that many of today’s mature, widely-used software systems are subject to latent configuration errors (referred to as LC errors) in their critically important   configurations—those related to the system’s reliability, availability, and serviceability.» Latent Errors 34

Slide 35

Slide 35 text

«LC [latent configuration] errors contribute to 75% of the high- severity issues and take much longer to diagnose, indicating their high impact and damage.» Latent Errors => серьезные инциденты 35

Slide 36

Slide 36 text

«Finding 3:   Resulting from Findings 1 and 2, 4.7%– 38.6% of the studied RAS [reliability availability serviceability] parameters do not have any early checks and are thereby subject to LC [latent configuration] errors which can cause severe impact on the system’s dependability.» Нет никаких проверок 36

Slide 37

Slide 37 text

«Such prevalence of LC [latent configuration] errors indicates the need for tool support to systematically rule out the threats.» «Another option to invoking the early checkers is to create a standalone checking program comprised of the checkers, and run it when the configuration file changes.» Нам нужны инструменты! 37

Slide 38

Slide 38 text

«This paper advocates early detection of configuration errors to minimize failure damage, especially in cloud and datacenter systems.» Мораль 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Практика

Slide 41

Slide 41 text

〉Нужны тесты на конфигурацию продакшена 〉Как написать такие тесты? Что делать? 41

Slide 42

Slide 42 text

— Надо проверить, что банковские переводы работают! — Как ты себе это представляешь? Отправили 10 миллиардов и ждем? — ??? Основано на реальных событиях Типичные тесты в продакшене 42

Slide 43

Slide 43 text

Мы не будет запускать систему

Slide 44

Slide 44 text

Пример 3 Тривиальные проверки

Slide 45

Slide 45 text

@pytest.mark.parametrize( ['path_to_config'], all_production_config_paths() ) def test_config_is_loadable(path_to_config): config = load_config(path_to_config) assert_that(config, not_(none())) 45 Проверяем, что конфигурация загружается

Slide 46

Slide 46 text

@pytest.mark.parametrize( ['path_to_config'], all_production_config_paths() ) def test_config_is_loadable(path_to_config): config = load_config(path_to_config) assert_that(config, not_(none())) 46 Проверяем, что конфигурация загружается

Slide 47

Slide 47 text

CONFIG_FOLDER = ‘path/to/config/folder’ CONFIG_FILE_PATTERN = 'config.txt' def all_production_config_paths(): return map( os.path.dirname, list_all_files_for_pattern( CONFIG_FOLDER, CONFIG_FILE_PATTERN ) ) 47

Slide 48

Slide 48 text

@pytest.mark.parametrize( ['config'], all_production_configs() ) def test_unique_node_ids(config): assert_that( config.NodeIds, sequence_has_unique_elements() ) 48 Простая проверка инвариантов

Slide 49

Slide 49 text

Пример 4 «Проект R» и порты

Slide 50

Slide 50 text

«Проект R» и порты 50 Primary  host1:port1 Secondary  host2:port2 Клиент  host1:port1  host2:port2

Slide 51

Slide 51 text

«Проект R» и порты 51 Primary  host1:port1 Secondary  host2:port2 Клиент  host1:port1  host2:port3

Slide 52

Slide 52 text

«Проект R» и порты 52 Primary  host1:port1 Secondary  host2:port2 Клиент  host1:port1  host2:port3

Slide 53

Slide 53 text

@pytest.mark.parametrize(…) def test_ports_are_valid(client, server_pri, server_sec): client_primary = client['primary']['connection'] client_secondary = client['secondary']['connection'] server_primary = server_pri[‘connection'] server_secondary = server_sec['connection'] assert_that(client_primary, equal_to(server_primary)) assert_that(client_secondary, equal_to(server_secondary)) 53

Slide 54

Slide 54 text

〉Не все клиенты смотрели на правильный secondary 〉Проблема была не видна до фактического отказа primary 〉Поиск проблемы в продакшне чрезвычайно дорог 〉Тесты на конфигурацию легко масштабируются на новых клиентов Мораль «Проект R» 54

Slide 55

Slide 55 text

Пример 5 «Проект K» и отказоустойчивость

Slide 56

Slide 56 text

«Проект К» — отказоустойчивость 56 Стойка 1 Стойка 2 Стойка 3 Каждая нода в отдельной стойке

Slide 57

Slide 57 text

«Проект К» — отказоустойчивость 57 Стойка 1 Стойка 2 Стойка 3 Отказала стойка — полет нормальный

Slide 58

Slide 58 text

«Проект К» — отказоустойчивость 58 Стойка 1 Стойка 3 Ошибка конфигурации — две ноды в одной стойке

Slide 59

Slide 59 text

«Проект К» — отказоустойчивость 59 Стойка 1 Стойка 3 Отказала стойка — часть системы стала недоступной

Slide 60

Slide 60 text

@pytest.mark.parametrize(…) def test_every_node_is_in_a_separate_rack(config): hostname_to_rack_id = { hostname: get_rack_id(h)   for h in config.hostnames } rack_ids = hostname_to_rack_id.values() assert_that(rack_ids, sequence_has_unique_elements()) 60

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Как написать метод get_rack_id()? 〉Разметить руками — подходит, если нод мало (< 10) 〉Получить информацию из внешней системы (если она у вас есть) Где узнать как ноды в стойках стоят? 62

Slide 63

Slide 63 text

〉Система не знает про расположение серверов в стойках 〉Но мы то знаем, как сервера расположены в стойках 〉«Внешние» проверки на основе этого знания легко нашли проблему 〉Такой тест легко масштабируется на новые инсталляции Мораль «Проект K» 63

Slide 64

Slide 64 text

Выводы

Slide 65

Slide 65 text

〉Конфигурация это как код, только хуже 〉Конфигурацию можно и нужно тестировать 〉Тесты на конфигурацию легко масштабируются на множество инсталляций/клиентов/и т.д. 〉Тесты на конфигурацию просто написать и получить много пользы Выводы 65

Slide 66

Slide 66 text

Напиши свой первый тест на конфигурацию, username@

Slide 67

Slide 67 text

Андрей Сатарин Ведущий инженер по автоматизации тестирования https://twitter.com/asatarin asatarin@yandex-team.ru

Slide 68

Slide 68 text

〉Три дня, которые потрясли нас в 2013 〉«Paxos Made Live – An Engineering Perspective» 〉«Early detection of configuration errors to reduce failure damage» 〉Gixy — open source от Яндекса, который сделает конфигурирование Nginx безопасным Ссылки 68