Production Clone

Я вот недавно про CI читал и прочитал очередной банал - test in production clone. Что, мол, непрерывная интеграция должна происходить на железе очень близком к production. И по характирестикам, и по настройке.

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

Во-первых, если у нас железо в 2 раза слабее, то и работает оно медленнее. В лучшем случае в 2 раза. Это значит, что разработчики ждут результатов тестов в 2 раза больше, а может и в 4. Вот здесь написано неплохо. Математика проста - обычно время разработчиков дороже железа.

Во-вторых, на более слабом железе загрузка CPU, памяти, I/O, распределяется по-другому, и работа по улучшению производительности скорее походит на работу гадалки. Например, если приложение обрабоатывает данные быстрее, то ему обычно нужно больше памяти в единицу времени - больше объектов в полете. Или CPU неплохо масштабируется, а вот I/O - нет, и при меньшем количестве прцессоров проблема с I/O может не проявляться.

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

Также, любое отличие по железу может на практике оказаться и не в лучшую сторону. Например, у нас в в продакшин используется SAN drive от EMC. Он дорогой и по идее быстрый, поэтому в тестах использовались RAID 0 массивы - ненадежные, но быстрые (чтобы имитровать скорость SAN). В процессе тестов в продакшене всплыли 2 проблемы:

• RAID 0 конфигурация оказалась быстрее, чем SAN drive
• При production ранах выяснился неприятных баг с настройкой - сумасшедная нагрузка на CPU при работе с SAN drive

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

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