Здравствуйте, меня зовут Алексей, я главный IT-архитектор банка «Ренессанс Кредит». Лет десять назад мы, как и многие компании, ускорили свое развитие благодаря сервис-ориентированной архитектуре (SOA). Но со временем требования к архитектуре менялись, и к данной парадигме стали возникать серьезные вопросы. В конце концов мы решили перейти от интеграционной шины ESB к микросервисам. На нашем примере я расскажу, почему стоит задуматься об эффективности SOA и что можно предпринять, если эта модель вас тоже не устраивает.

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

Нагрузочное тестирование во многом схоже с учениями по ГО и ЧС. Лучше заранее понимать, как будет выглядеть та или иная ситуация, чем пытаться в панике сориентироваться. Помимо собственных тестов и собранных на production проблем, можно перенять опыт коллег по индустрии. Специально для проекта «Календарь тестировщика» Дмитрий Воротников, тестировщик Контура, на примере ЧП крупных IT-компаний вывел несколько простых, но важных правил тестирования сервиса.

Изменившийся профиль нагрузки

Когда говорят о нагрузочном тестировании обычно имеют ввиду capacity testing. У онлайн-магазинов есть Black Friday и Cyber Monday — время распродаж и экстремального увеличения нагрузки на все сервисы. В Контуре похожие скачки трафика бывают в последние дни отчетности в контролирующие органы. По какой бы причине ни выросло число посетителей, нельзя допустить недоступности операций, ошибки или увеличения времени ответа. С помощью тестирования емкости сервиса мы убедимся, что пользователи не будут злобно дергать мышкой или уходить к конкурентам, а смогут комфортно и продуктивно работать.

Проводя тестирование с профилем нагрузки, повторяющим типовой за последние месяц, год или два, можно столкнуться с проблемой, какая была у Amazon Simple Storage Service 15 февраля 2008 года. Доступ к данным в S3 регулируется AWS Authentication service. Запросы к нему зашифрованы и требуют на обработку больших вычислительных ресурсов. Amazon поддерживали столько серверов, сколько было необходимо для обработки нагрузки предыдущих двух лет. В отчетный день в 3:30 утра инженеры заметили, что количество аутентификационных запросов увеличилось. Это перегрузило инфраструктуру AWS и стало невозможно обрабатывать все запросы. Чтобы обработать возросшую нагрузку, пришлось вводить дополнительные мощности. До 6:48 все проекты, использовавшие S3, были недоступны.

Красота, как известно, требует жертв, но и мир обещает спасти. Достаточно свежий (2015г) визуализатор от Google призван помочь разобраться с процессами, происходящими в сетях глубокого обучения. Звучит заманчиво.

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

Чтобы опыт не прошел зря, решила поделиться максимально простым описанием инсайтов с хабравчанами, ибо рускоязычных гайдов мало, а англоязычные все как на одно лицо. Может, такое введение поможет вам сократить время на знакомство с Tensorboard и количество ругательных слов на старте. Также буду рада узнать, какие результаты он дал в вашем проекте и помог ли в реальной задаче.

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен...

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

В типичной реализации генетический алгоритм оперирует параметрами какой-то сложной функции (диофантовые уравнения в статье "Генетический алгоритм. Просто о сложном" mrk-andreev) или алгоритма ("Эволюция гоночных автомобилей на JavaScript" ilya42). Количество параметров неизменно, операции над ними тоже изменить невозможно, как генетика не старается, потому что они заданы нами.

Хьюстон, у нас проблема

Сложилась странная ситуация — прежде чем применять генетические алгоритмы (ГА) к реальной задаче, мы сначала должны найти алгоритм, которым эта задача в принципе решается, и только потом его попытаться оптимизировать с помощью генетического алгоритма. Если мы ошиблись с выбором «основного» алгоритма, то генетика не найдет оптимум и не скажет, в чем ошибка.

Часто, а в последнее время и модно, вместо детерминированного алгоритма использовать нейронную сеть. Тут у нас тоже открывается широчайший выбор (FNN, CNN, RNN, LTSM, ...), но проблема остается той же — выбрать нужно правильно. Согласно Википедии "Выбирать тип сети следует, исходя из постановки задачи и имеющихся данных для обучения".

А что, если...? Если заставить ГА не оптимизировать параметры, а создавать другой алгоритм, наиболее подходящий для данной задачи. Вот этим я и занимался ради интереса.

Какое-то время назад решил написать небольшое приложение, чтобы потренироваться работе с вебсокетами. Из питоновских фреймворков мне показалось удобней изкоробочная поддержка их в tornado. Поскольку игрушка предельно простая, может кому-то показаться полезной как пример. Это многопользовательская «змейка».

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