Как мы обслуживали ИТ-инфраструктуру “Лужников” во время Чемпионата мира

Мне довелось участвовать в проекте по созданию инженерной и ИТ-инфраструктуры Большой спортивной арены «Лужники». Работы длились несколько лет и завершились сопровождением внедренных нами решений во время проведения Чемпионата мира по футболу FIFA. Под катом — о том, как мы внедряли и обслуживали HD Wi-Fi на крупнейшей спортивной площадке страны, с какими проблемами столкнулись и как нам помогали миникомпьютеры Raspberry Pi.

Источник

13 ноября 2017 года

Главная новость дня: На БСА Лужники будет две сети Wi-Fi для болельщиков, а не одна. Сейчас точки Wi-Fi для болельщиков установлены только в скай-боксах и подтрибунном пространстве. В 2014 году, когда началась реконструкция, на трибунах стадиона заказчик решил Wi-Fi не строить, поскольку данный посыл присутствовал в требованиях FIFA в форме скромного пожелания. Теперь у заказчика есть официальное письмо за подписью ИТ-директора FIFA Дика Вайлза (Dick Wiles). Суть письма заключается в том, что теперь HD Wi-Fi на трибунах стадиона – это не мягкая просьба, а жесткое требование. Не очень понятно, что теперь с этим делать. Закупленные в 2014 году и установленные согласно проекту точки доступа и контроллеры Wi-Fi HPE ушли в такой end-of-sale, что расширить сеть на существующих контроллерах нет никакой возможности. Будем строить на Лужниках еще одну Wi-Fi сеть. В идеале решение должно пройти опытную эксплуатацию 23 марта 2018 года, на тестовом матче Россия-Бразилия. На 100% все должно работать 14 июня, на церемонии открытия Чемпионата мира по футболу FIFA.

15 ноября 2017 года

Поскольку это не первый проект «ЛАНИТ-Интеграции» по строительству HD Wi-Fi на стадионах (о первом проекте можно прочитать тут), уже понятны основные моменты, на которые стоит обратить внимание.

  1. Все клиенты должны пройти аутентификацию перед получением доступа в Интернет.

    Если речь идет о гостевом доступе в Интернет в общественном месте, это требование российского законодательства. Наиболее понятный способ решить вопрос – предложить абоненту сообщить свой номер мобильного телефона в обмен на получение одноразового пароля по SMS.
  2. Точки доступа будут стоять не там, где это оптимально, а там, где разрешат.

    Точка доступа может висеть на стадионе только при одновременном соблюдении трех условий: а) не заслоняет обзор; б) руками не дотянуться; и в) можно подвести «витую пару». Как только план расстановки точек доступа попадет на согласование людям, ответственным за общественный порядок, в случае несоблюдения хотя бы одного из условий точку демонтируют, а любые доводы типа радиообследования, рекомендаций вендоров и т.д. будут трактоваться как отговорки в пользу бедных.
  3. Всегда есть жалобы на работу Wi-Fi, с которыми непонятно что делать.

    «Что-то я слишком долго скачиваю файл через WhatsApp». «Вчера моя девушка была на стадионе и не смогла подключиться». Крайне редко претензия содержит сведения, хоть как-то помогающие в работе. В разгаре матча совершенно без толку уточнять у человека MAC-адрес телефона, просить прислать скриншоты и т.д. Если мы не хотим бегать по стадиону в бесконечных попытках проверять качество работы HD Wi-Fi, надо придумать, что делать с подобными обращениями.
  4. Трудно объективно понять, насколько хорошо работает HD Wi-Fi на стадионе.

    Абонент может быть недоволен качеством Wi-Fi из-за кучи «плавающих» вещей, которые даже неподконтрольны тому, кто занимается обслуживанием ИТ-инфраструктуры объекта. Может не прийти SMS-код из-за глюков телефона, загруженности сотовой сети или сбоя на стороне SMS-оператора. Возможны задержки открытия web-страниц из-за проблем на стороне операторов связи, или хостинг-провайдеров. Человек банально не поймет, как подключиться… Качества сигнала и отсутствия помех в беспроводной среде передачи данных по определению никто не гарантирует.

Антенна WiFi на стадионе. Обратите внимание, что она находится за стеклом, что несколько ухудшает качество сигнала, зато физически защищает антенну от болельщиков.

15 декабря 2017 года

Заказчик принял окончательное решение, что вторая сеть Wi-Fi на стадионе будет строиться на оборудовании Cisсо Systems. По самым предварительным расчетам, на трибунах стадиона надо повесить порядка 500 точек доступа. Инженеры Cisco предлагают делать проект на контроллерах AIR-CT8510-500-K9 и на точках AIR-CAP3702E с антеннами AIR-ANT2513P4M-N= и AIR-ANT2566D4M-R=. Если мы сегодня же закажем оборудование, оно придет минимум через полтора месяца, то есть 1 февраля. А 23 марта – тестовый матч. Сроки крайне сжатые, так что контроллеры решили заказывать сразу. Для мониторинга инцидентов ИБ было решено добавить в состав решения и тоже сразу заказать пару NGFW на базе МЭ Fortinet в разрыв между нашей сетью и сетью оператора связи. Заказывать точки доступа и радиоантенны пока стремно, ибо мы смутно представляем, сколько точек нужно и куда их вешать. Надо срочно начинать радиообследование.

Источник

18 декабря 2017 года

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

20 декабря 2017 года

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

Первым отпал вариант пробивать плиту перекрытия: померили затухание сигнала в диапазоне 2,4 ГГц при сквозном прохождении плиты. Оно составило -80dBm, и это похоронило решение.

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

Наиболее соблазнительно смотрится монтаж на кровле: прокладывать кабель по ходовым мосткам куда проще, тем более что там даже есть оптика и климатические телекоммуникационные шкафы. Но и тут не судьба: среднее расстояние от ходовых мостков кровли по прямой до трибун стадиона «Лужники» составляет порядка 40м при проектной норме максимум в 20м для HD Wi-Fi.

Остается единственный вариант – раскидывать точки по периметру секторов стадиона. Это означает неизбежную неравномерность радиопокрытия плюс проработку решений по защите от посягательств на оборудование со стороны гостей. Других способов выполнить требования FIFA попросту нет.

25 декабря 2017 года

Мы разделили трибуны стадиона на типовые сектора и провели радиообследование одного типового сектора. Для обследования мы попросили у Cisco Systems на тест точки АIR-CAP3702E с антеннами, которые предлагал вендор. По итогам обследования удалось наметить способы крепления оборудования. Чтобы болельщики не могли дотянуться до точек доступа, нужны специальные монтажные кронштейны. Придется делать их на заказ, причем ожидается несколько типов кронштейнов, в зависимости от типовых мест установки точек доступа. Еще нам нужны монтажные боксы, т.к. предоженные вендором точки доступа не являются вандалостойкими, а вандалостойкие точки доступа Cisco для HD Wi-Fi стоят значительно дороже и точно не появятся на объекте к матчу Россия-Бразилия.

28 декабря 2017 года

Проектировщики получили результаты радиообследования одного сектора стадиона и по этим данным нарисовали задание на подвод кабелей СКС по всем секторам. Определились с требуемым количеством точек доступа – 430 штук. Это позволило начать закупку точек, выдать задание производителю кронштейнов и монтажных боксов, а также прикинуть, в каких кроссовых нужно установить дополнительные коммутаторы доступа, чтобы иметь возможность подключить наши точки доступа. Уже понятно, что для проекта нужны 12 разных типов монтажных кронштейнов. Закупку кронштейнов пока придется ограничить пилотной партией, так как сперва заказчик должен увидеть решение в натуре и убедиться, что точки доступа никому не мешают. Спецификацию на коммутаторы доступа, антенны и точки Wi-Fi отдали в заказ в полном объеме. Если заказанное оборудование придет в конце февраля, у нас будет всего месяц до начала тестового матча.

Фрагмент монтажного чертежа одного из используемых на стадионе кронштейнов

15 января 2018 года

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

Тем временем инженеры вовсю заняты проработкой решения SMS-аутентификации абонентов. За это должна отвечать отдельная подсистема. На рынке есть несколько производителей ПО и операторов связи, у которых можно эту подсистему купить – либо как ПО, либо как сервис. Мы остановились на продукте под названием WNAM от ООО «Нетамс», который работал у нас на стадионе «Открытие Арена».  Вот как все это должно в общих чертах выглядеть.

Общая архитектура системы

WNAM взаимодействует с контроллерами Wi-Fi по протоколу RADIUS. Когда абонент пытается подключиться к SSID, контроллер спрашивает у WNAM, есть ли клиент с MAC-адресом, от которого пришел запрос на подключение, в базе зарегистрированных пользователей. Если есть – клиент получает доступ в Интернет и опционально редиректится на стартовый web-сайт (в нашем случае это портал FIFA welcome2018.com). Если его нет, контроллер редиректит пользователя на портал аутентификации и пока что никуда, кроме этого портала, его не пускает. Портал представляет собой web-страницу, которая крутится на сервере авторизации WNAM. Дизайн портала аутентификации для каждого проекта уникален и разрабатывается отдельно (в нашем конкретном случае его прислал Оргкомитет FIFA). Во время ЧМ стартовая страница аутентификации должна выглядеть следующим образом:

Как только пользователь вводит номер своего телефона, WNAM генерирует код авторизации и отправляет его в виде SMS через утилиту kannel по протоколу SMPP СМС-оператору, а тот через соответствующего сотового оператора – конечному абоненту.

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

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

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

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

1 февраля 2018 года

На объект пришли контроллеры Wi-Fi, коммутаторы доступа и межсетевые экраны. Оборудование смонтировали, приступили к пуско-наладочным работам. Коллеги из «Нетамс» начали настраивать WNAM. Тем временем заказчику позвонили из соответствующих ведомств и напомнили о высокой ответственности, которая возлагается на всех нас в части отработки потенциальных инцидентов информационной безопасности на матчах Чемпионата мира.

Чтобы сэкономить время, активно проводим с заказчиком согласование пилотных монтажных узлов в неофициальном порядке. Объясняем, что антенны и точки доступа уже закуплены и едут на объект, поэтому максимум, что мы можем поменять в условиях крайне сжатых сроков – это чуть подвинуть точки или немножко подправить кронштейны. В противном случае проект можно будет сворачивать. Заказчик идет навстречу и вносит в пилотные решения минимальные корректировки. Таким образом мы потихоньку согласовываем в заказ проектные партии типовых монтажных кронштейнов.

12 февраля 2018 года

Оргкомитет прислал уточненные требования к работе сети Wi-Fi для болельщиков. Основные изменения касаются статистических отчетов, которые Оргкомитет будет требовать с нас на каждом матче Чемпионата Мира. Некоторые требования – весьма специфические. Помимо очевидных вещей типа графиков загрузки каналов связи и количества абонентов требуется вычислять соотношение пользователей в диапазонах 2,4 и 5 ГГц, а также данные о том, как абоненты проходят различные этапы аутентификации, да еще и с разбивкой по странам, из которых эти абоненты приехали. Статистику Оргкомитет FIFA желал видеть не только в форме интерактивных графиков, но и в виде таблиц с возможностью автоматического экспорта данных в excel и pdf, причем перед экспортом должна быть доступна опция задания временного промежутка, за который нужны данные. Такие требования наводили на мысль об отдельной «зонтичной» системе сбора и анализа статистики, которая будет сводить данные из различных компонентов сервиса, поскольку сведения об утилизации каналов операторов связи, например, надо брать из межсетевого экрана, статистику по аутентификации – из логов WNAM, а данные по количеству абонентов в диапазонах 2,4 и 5 ГГц  – только на контроллерах и больше нигде. Так в нашем проекте появилась тяжелая артиллерия в виде системы сбора и анализа статистики Splunk Enterprise.

14 февраля 2018 года

Источник

А что все-таки делать с жалобами на плохую работу Wi-Fi? Как оценивать работу сервиса, если ты контролируешь не все его компоненты, «плавающих» проблем слишком много, а полученные от абонентов описания инцидентов лишь отнимают время? Почему бы не раскидать по стадиону какие-то устройства, которые будут вести себя в сети Wi-Fi так же, как наши пользователи, и при этом отсылать нам детальные логи о том, как обстоят дела в действительности? Это должны быть устройства, которые могли бы сами подключаться к сети Wi-Fi, аутентифицироваться на WNAM, работать в Интернете, отключаться и делать все это по скрипту снова и снова, присылая нам детальные логи на каждом шаге. Безусловно, все это еще должно недорого стоить, так как бюджет проекта практически исчерпан. Надо будет обсудить эту тему с инженерами, может удастся что-то придумать.

15 февраля 2018 года

Обсудили с инженерами идею проактивного мониторинга Wi-Fi путем имитации пользовательской активности. Вспомнили о Raspberry Pi. В теории его можно наделить функционалом мобильного устройства, если оснастить GSM-модемом с SIM-картой, на которую будут приходить SMS с одноразовым кодом аутентификации. Питать изделие можно по PoE, через PoE-экстрактор.

Внешний вид Raspberry Pi 3 model B без корпуса

26 февраля 2018 года

Инженеры выдали проект устройства проактивного мониторинга на базе Raspberry Pi 3 Model B. Предполагается подключить к нему Wi-Fi-адаптер Wi-Fi  D-Link DWA-171/RU/A1A, поскольку внутренний Wi-Fi-адаптер не обладает поддержкой сетей в диапазоне 5GHz (жаль что версия B+, где есть встроенный адаптер на оба диапазона, выйдет спустя месяц), а также 3G/GSM-модем Huawei E3372h-153USB  с SIM-картой. Питание миникомпьютера можно осуществлять через промежуточный PoE-экстрактор Upvel UP-102S. Все это будет упаковано в пластиковый корпус.

На миникомпьютере под управлением ОС Raspbian устанавливается интернет-браузер Firefox и компонент Splunk forwarder, который должен пересылать логи в Splunk Enterprise. Сценарий активности микрокомпьютера задается отдельным python-скриптом. Отправка логов осуществляется по проводному Ethernet, а не по Wi-Fi, что является еще одним достоинством решения.

В основе работы скрипта проверки лежит взаимодействие с браузером и выполнение в нем действий, аналогичных тем, что совершает пользователь в процессе работы с Wi-Fi (загрузка страницы аутентификации, ввод номера, на который зарегистрирована сим-карта, ввод полученного кода по SMS, несколько тестов скорости работы в интернете). Для этого идеально подошла библиотека Selenium, созданная для языка Python.

Вот такое получилось изделие. На фото — корпус со снятой крышкой.

28 февраля 2018 года

Идея с Raspberry заказчику понравилась. Он согласился включить в состав решения 50 миникомпьютеров и закупить для них SIM-карты трех сотовых операторов. Теперь, если во время матча кто-то позвонит и начнет жаловаться на плохую работу Wi-Fi, у нас будет 50 эталонных устройств, по которым можно увидеть общую картину работы сервиса на стадионе.

5 марта 2018 года

Пришла первая партия монтажных кронштейнов. Все точки доступа и антенны уже на объекте, кабели СКС протянуты, а кронштейнов не хватает. Монтируем то, что есть. Договорились с заказчиком, что к тестовому матчу Россия-Бразилия будут смонтированы точки доступа на типовых секторах, чтобы иметь возможность проверить правильность принятых решений по расстановке. Жаль, что до церемонии открытия мы точно не успеем протестировать Raspberry.

15 марта 2018 года

Нас пригласили на очередное совещание по вопросам информационной безопасности. На совещании мы поинтересовались, какие риски ИБ во время Чемпионата были бы наиболее значимыми. Оказалось, самое неприятное, что может произойти – это трансляция на видеотабло стадиона контента экстремистской направленности. Мы спросили, что будет, если кто-то додумается во время матча вывести на табло порнографию. Нам ответили, что это, конечно, тоже неприятно, но есть вещи и похуже.

20 марта 2018 года

Сегодня мы завершили настройку зеркалирования трафика на интерфейсы серверов СОРМ-2, СОРМ-3 и СОПКА, которые установлены прямо в дата-центрах стадиона. Пришлось немного повозиться с перенаправлением логов с WNAM и межсетевого экрана в СОРМ3, чтобы если что было бы откуда брать частный IP адрес, MAC-адрес и номер SIM-карты любого, кто авторизуется в нашей сети.

23 марта 2018 года. Тестовый матч «Россия — Бразилия»

Сегодня на стадионе товарищеский матч между сборными России и Бразилии, так что монтаж точек доступа приостановлен. К тестовому матчу мы успели повесить точки доступа только на нижнем ярусе трибун стадиона (это 50% от общего объема) плюс Wi-Fi в подтрибунном пространстве, который уже и так работал. Главная задача на сегодня – убедиться, что наше типовое решение по расстановке точек доступа будет работать в условиях большого скопления абонентов, ну и общее сопровождение ИТ-инфраструктуры тоже на нас.

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

Каждый из инженеров отвечает за работу какой-то отдельной ИТ-системы: система хранения данных, серверы, виртуализация, AD DS, Wi-Fi…  У нас с руководителем проекта отдельный стол и большой монитор, на который выводятся дашборды системы мониторинга Splunk Enterprise. Splunk Enterprise собирает логи от всех ИТ-систем стадиона, за которые мы отвечаем. Он же показывает статистику работы Wi-Fi высокой плотности.

Статистика очень детальная, есть даже процент распределения пользователей по диапазонам 2,4 и 5 Ггц (долго думали, как реализовать, в итоге решили периодически обращаться Splunk’ом по API к Wi-Fi контроллерам Cisco и HPE через посредников в лице системы мониторинга HP IMC, к которой подключены контроллеры точек HP, и Cisco Prime, к которой подключены контроллеры Cisco).

Поскольку в помещении нет окон, мы понятия не имеем, что происходит на поле. Поэтому в углу комнаты стоит телевизор, который транслирует прямой эфир «Первого канала». По этому телевизору мы с руководителем проекта будем смотреть все матчи ЧМ-2018 на стадионе «Лужники».

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

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

16 апреля 2018 года

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

Поэтому Оргкомитет прислал уточненные требования по SMS-аутентификации. Если на Чемпионате мира кто-то попытается зарегистрироваться в сети Wi-Fi по зарубежному номеру, ему будет предложено ввести номер FAN-ID или паспорта болельщика. Реализация этого требования требует отдельных плясок с бубном на уровне WNAM в части интеграции системы SMS-аутентификации с базами FAN-ID. Особенно с учетом того, что портал FAN ID, с которым надо интегрироваться, еще пребывает в стадии активной разработки.

15 мая 2018 года

Добавили на WNAM страничку портала аутентификации для обладателей зарубежных SIM-карт. Поскольку база FAN ID еще не введена в эксплуатацию, аутентификация по FAN ID пока не работает.

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

12 июня 2018 года

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

14 июня. Матч «Россия-Саудовская Аравия»

Я стою в углу конференц-зала «Лужников», а в конференц-зале вовсю идет подготовка к совещанию перед церемонией открытия Чемпионата Мира. Рядом со мной — ящик пива, на котором лежит лист бумаги с надписью «Райдер Р. Вильямс. Не брать». Церемония открытия начнется через несколько часов.

Только что мы закончили последнее, что нам оставалось сделать на стадионе перед Чемпионатом мира, – смонтировали и подключили ТВ-панель на президентской VIP-трибуне, на которую будут выводить статистику матча и повторы интересных моментов. Не удержались и посидели в креслах, в которых скоро будут сидеть Владимир Путин, наследный принц Саудовской Аравии Мухаммед бен Салман и президент ФИФА Джанни Инфантино.

Источник

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

ИТ-инфраструктура стадиона отработала матч без инцидентов. Однако смущает низкий процент пользователей, которые зашли на портал SMS-аутентификации и успешно ее прошли – 30% при ожидаемых 50%. Мы предположили что всё благодаря пяти голам, забитым сборной России в ворота сборной Саудовской Аравии, однако Оргкомитет с нами не согласен. Посмотрим, что будет на следующих матчах.

Источник. Девушка решила сфотографироваться на фоне антенн HD WI-FI

15 июня 2018 года

Мы проанализировали логи WNAM и выяснили, что во время вчерашнего матча очень много людей при регистрации на портале WiFi HD почему-то неправильно вводили свой FAN ID. Если присмотреться к паспорту болельщика, то там есть три номера, похожие на те, что требует страничка портала аутентификации. Предположили, что болельщики не знали, какой конкретно номер требуется ввести. В итоге мы совместно с Оргкомитетом FIFA придумали пару идей, которые должны улучшить качество работы сервиса Wi-Fi на стадионе:

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

17 июня 2018 года. Матч «Германия — Мексика»

В самый разгар матча от стюардов поступает жалоба на проблемы с доступом к Wi-Fi в VIP-зоне. Нас проводят в скай-бокс. В скай-боксе накрыт стол и тусуется толпа мексиканцев. В углу – барная стойка. Она прямо-таки ломится от самого разнообразного алкоголя. Возле барной стойки стоит здоровенный мексиканец. У него в руках пиво и телефон. Ему тяжело стоять. Это он жаловался на проблемы с Wi-Fi.

Общаемся на английском. Мы объясняем, что вот в это поле мексиканец должен ввести свой номер мобильного:

– Назовите нам номер вашего телефона. Вы помните номер вашего телефона?

Мексиканца шатает. Сначала он вообще не помнит номер своего телефона, но с третьей попытки все-таки его вспоминает. Мы продолжаем объяснять:

– Теперь вы должны ввести номер FAN ID. Покажите Ваш паспорт болельщика, пожалуйста.

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

Доступ в Интернет для мексиканца мы все-таки организовали. А еще в конце матча мне прислали видеозапись того, как болельщики облили пивом стюарда. Нелегко вспомнить номер своего телефона, когда вокруг тебя бурлит магия Мундиаля.

Источник

18 июня 2018 года

Каждый раз после матча мы проводим внутреннее совещание, на котором обсуждаем итоги мероприятия, можно ли повысить качество работы инфраструктуры и как это сделать. В этот раз совещание было посвящено решению на Raspberry Pi, которое во время матча Россия-Мексика заработало в полную силу, но удивило нас странной статистикой. Утром, когда на стадионе никого не было, Raspberry информировали нас о том, что Wi-Fi работает нормально. Однако, как только болельщики начали занимать свои места, все миникомпьютеры начали информировать нас о полном отсутствии сервиса. Одновременно Splunk и подсистема отчетности WNAM сообщали, что подключения идут нормально. Получается, что данные противоречат друг другу.

В ходе пошаговой отладки скрипта Raspberry выяснилось, что его надо существенно дорабатывать, так как в текущем виде он выдает огромное количество ложных ошибок. Было решено выпустить новую версию скрипта, которая будет содержать 15 дополнительных проверок. Заменили достаточно тяжелый браузер Firefox на PhantomJS, что в итоге позволило в два раза повысить скорость выполнения проверок. Еще одной возможностью системы стало отображение на страницы статистики в Splunk’е скриншотов страницы аутентификации для визуальной оценки возможных проблем.

Для оперативной заливки новых версий скрипта на 50 устройств решили установить оркестратор Ansible.

Анализ скрипта выявил и совершенно неочевидные вещи: например, был момент, когда все Raspberry начали ругаться на неверные одноразовые пароли. Оказалось, все микрокомпьютеры помимо кодов получали и другие SMS-сообщения, например, спам или сообщения от МЧС об ухудшении погоды. В цикле проверки такие SMS-сообщения попадали в буфер раньше сообщений, сгенерированных WNAM’ом, и, соответственно, воспринимались скриптом как одноразовый пароль.

20 июня 2018 года. Матч «Португалия-Марокко»

«Да что, черт побери, делать с этим Марокко?» – в порыве воскликнул наш инженер, занимающийся мониторингом WNAM, когда увидел растущую очередь отправки исходящих SMS-сообщений без delivery report. У нас в логах была статистика по отправке SMS-сообщений по всем операторам, у которых в открытых базах есть коды, и мы могли видеть, в какие страны SMS приходят нормально, а в какие – с задержкой. Королевство Марокко занимало в нашей статистике прочные аутсайдерские позиции. В начале второго тайма было принято решение переадресовать рассылку на другого SMS-оператора, и это несколько улучшило ситуацию.

26 июня 2018 года. Матч «Дания-Франция»

Источник

По телевизору привычно шла прямая трансляция матча со стадиона. Просмотр трансляции нужен нам, чтобы чувствовать динамику активности клиентов Wi-Fi: во время игры она падает, а в перерывах наоборот растет.

По сравнению с матчем «Португалия-Марокко» сопровождение выдалось более спокойным, так как Дания и Франция – европейские страны и статистика по SMS для них ожидаемо оказалась лучше, чем для Марокко. Поэтому мы посвятили матч отладке скриптов Rasberry и настолько увлеклись этим процессом, что только к концу матча поняли: все это время по телевизору шла трансляция совершенно другого матча, не со стадиона Лужники, а со стадиона Фишт.

В метро после матча ко мне с расспросами пристал какой-то мужик:

– Слушай, а кто только что играл на Лужниках?

Я с трудом вспоминаю названия команд:

– Дания и Франция. Да, Франция.

– А какой счет?

Счет я совершенно не помню, так так матч не смотрел, о чем и сообщил. Когда мужик понял, что я еду со стадиона и не знаю счета, он посмотрел на меня с нескрываемым изумлением.

11 июля 2018 года, матч «Англия – Хорватия»

В середине второго тайма на межсетевом экране обнаружилась подозрительная сетевая активность одного из подключившихся абонентов. Межсетевой экран блокировал с его IP-адреса большое количество соединений по нестандартным портам (которые были закрыты политикой межсетевого экранирования). Запросы шли в Россию, страны СНГ и Европы. Поскольку это был инцидент ИБ, безопасники с энтузиазмом взялись за дело.

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

15 июля 2018 года, матч «Франция-Хорватия», финал

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

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

Заключение

Участие ЛАНИТ в реконструкции ИТ-инфраструктуры Большой спортивной Арены «Лужники» к Чемпионату мира завершилось. За четыре с половиной года работы мы построили с полсотни слаботочных и ИТ-систем и три дата-центра, повесили полторы тысячи камер и 650 ТВ-панелей, настроили ЛВС на 12 тысяч портов и сделали аж две сети Wi-Fi высокой плотности для болельщиков Чемпионата – 430 точек доступа Cisco в чаше стадиона и 650 точек доступа HP в подтрибунном пространстве.

Какие неочевидные особенности были выявлены у решения в ходе пуско-наладки и опытной эксплуатации HD WiFi на БСА Лужники:

  • SMS-аутентификация – это не решение ‘из коробки’. Развертывание эффективной системы требует высококвалифицированной настройки ‘под себя’ и активного мониторинга.

    Это – разработка портала аутентификации, настройка взаимодействия с SMS-оператором, и на закуску самое сложное – настройка интеграции с контроллерами Wi-Fi. Хотя RADIUS – это стандартный протокол, у него есть свои особенности взаимодействия с каждой моделью контроллера. Некоторые модели контроллера вообще не получится интегрировать. Нам повезло: с контроллерами Cisco 8510 и HPE870 WNAM заработал, причем дружить с HPE870 он отказывался практически до последнего. За счет интеграции с WNAM обоих контроллеров хоть как-то удалось решить задачу роуминга между сетями Wi-Fi на Cisco и HPE. Если человек переходил от зоны действия одной сети к зоне действия другой, сессии, конечно, обрывались, но за счет наличия общей базы данных абонентов переключение проходило более-менее незаметно.
  • Доставка SMS не всегда работает так, как хотелось бы. Особенно когда речь идет об экзотических странах.

    Есть куча причин, по которым SMS может прийти слишком поздно (мы знаем пару венгров, которые ждали SMS с кодом по 5 минут),  либо не прийти вообще. Одна их них — спам-фильтры на стороне SMS операторов. Например, одноразовый код доступа в SMS практически гарантированно не придет абоненту с иностранной SIM-картой, если идентификатор отправителя будет представлять собой не номер телефона, а имя (например, Luzhniki). Последовательность из нескольких одинаковых сообщений одному и тому же номеру тоже может быть воспринята оператором как спам и заблокирована. Проблема усугубляется тем, что иногда сообщение передает не один, а цепочка неизвестных вам SMS-операторов, у каждого из которых – свои настройки спам-фильтров.
  • Абонент может отказаться от аутентификации по совершенно неочевидным причинам.

    Не всем нравится идея сообщать номер своего мобильного телефона в обмен на доступ в интернет. Нормальной считается ситуация, когда доступ в интернет получает 50% от тех, кто попадал на портал аутентификации. Тем не менее, для повышения качества сервиса всегда полезно выяснять причины, по которым абоненты пытались зарегистрироваться в сети, но в Интернет не попали. Возможно, с этим удастся что-то сделать.
  • HD Wi-Fi нужен болельщикам на стадионе куда меньше, чем нам хотелось бы.

    Когда мы проектировали HD Wi-Fi, мы рассчитывали, что им одновременно воспользуется 20% болельщиков, хотя на всех матчах показатели оказались ниже этого значения. Среди методов, которыми мы пользовались для увеличения числа пользователей, сработали: голосовые и текстовые объявления о том, что на объекте работает бесплатный Wi-Fi, а также добавление на портал аутентификации детальной инструкции по подключению.
  • Вы никогда не будете единственным, кто раздает Wi-Fi на объекте.

    Во время последнего матча мы запустили сканирование сети на предмет Rogue AP и только на трибунах стадиона насчитали более 3000 «чужих» устройств, работающих в режиме точки доступа. Причем это были как сотовые телефоны, раздающие Wi-Fi, так и специальные решения зарубежных операторов, например, Skyroam и Roamingman. Возле входных турникетов висело объявление, запрещающее раздавать на стадионе Wi-Fi, но не похоже, что оно хоть как-то работало.
  • Проактивный мониторинг Wi-Fi HD, имитирующий активность пользователей, может быть эффективен, но требует больших трудозатрат при внедрении и сопровождении

    Намного веселее получать данные от микрокомпьютеров Raspberry, чем сидеть и ждать очередной жалобы от недовольных пользователей. Разумеется, Raspberry капризничали, а написание и отладка скриптов заняли у нас много времени. Зато это позволило взглянуть на сервис Wi-Fi HD с другого ракурса, направило процесс мониторинга в более конструктивное русло и в итоге действительно помогло нам локализовать несколько «плавающих» ошибок, что позитивно сказалось на качестве сервиса. К тому же, всякий раз, когда кто-то обращался к нам с вопросами о работе Wi-Fi HD у его девушки, нам было что ему ответить.


ссылка на оригинал статьи https://habr.com/post/423645/

Типичные ошибки бизнеса в интернете, которых вы сможете избежать

Больше месяца назад пять компаний стали победителями акции “Бесплатное продвижение” и выиграли раскрутку своих сайтов силами объединенной команды специалистов Rookee и Ingate. Проблемы, с которыми мы столкнулись в ходе работ над ресурсами призеров, оказались весьма нетривиальными в плане подбора решений. Но довольно популярными среди владельцев сайтов. Публикуем краткий обзор с вариантами решений и советами профи, чтобы предостеречь владельцев сайтов от типичных ошибок и недальновидных поступков.

Акция “Бесплатное продвижение” продлится 6 месяцев. Компании-участники были выбраны случайным образом методом жеребьевки. Проект призван наглядно продемонстрировать, каких результатов можно добиться, запустив продвижение сайта практически с нуля. И что для этого нужно сделать. Для этого на сайте сервиса выкладывается информация о результатах продвижения, плюс пошаговое описание проделанной работы.

Но обо всем по порядку.

Когда проще написать новый сайт

В интернет-магазине Softplaid гордятся тем, что здесь можно найти плед на любой запрос, но вот сайт компании с точки зрения seo нужно было дорабатывать и дорабатывать. Специалисты Rookee составили список всех работ по технической оптимизации и передали задания на реализацию. На этом этапе и обнаружилась главная проблема. Оказалось, что платформа, на которой расположен сайт, не позволяет вносить доработки: ни дополнительных метрик, ни подключения Яндекс.Вебмастера — ничего. Все это было возможно только при переходе на тариф с неадекватной суммой платежей в месяц. Посчитали и поняли: выгоднее написать новый сайт с учетом пожеланий SEO-специалиста с нуля и перейти на новый хостинг, чем соглашаться на этот людоедский тарифный план.

Результаты за месяц работ

Клиент уже одобрил прототип, все работы по оптимизации ведутся на новом сайте, который скоро заменит старый.

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

Когда надо проверить структуру сайта

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

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

Результаты за месяц работ:

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

Совет Rookee: Один из основополагающих этапов создания сайта — это работа над его удобной и понятной структурой. Именно она определяет расположение, логику и взаимосвязь элементов ресурса. Продумывайте структуру, приглашайте профессионалов к этому этапу работы, тогда вы сможете легко его развивать и добавлять любые обновления.

Когда размер не имеет значения

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

Результаты за месяц работ:

Провели техническую оптимизацию и выложили метатеги, учли сильные стороны интернет-магазина: региональное представительство, полноту каталога. И сразу увидели положительную динамику сайта.

Совет Rookee: Да, этот пример не о проблемах, а о том, как надо работать. Хороший пример, беспроблемный старт продвижения. Просто показать, что и так тоже бывает. Если на начальных этапах создания сайта учитывать все требования SEO, то он будет готов к эффективному продвижению в поисковиках сразу же после запуска. В этом случае можно сразу рассчитывать на целевой трафик — структура будет полностью отражать спрос.

Когда хостинг поменяли, а про доступы забыли

Для сайта Sklad27 были подготовлены все технические задания и переданы специалистам, как вдруг оказалось, что доступов к ресурсу нет. Точнее они были, однако, буквально на 5-6 день после победы в акции сайт перестал работать и пришлось срочно менять хостинг. Доступы к FTP и SSH, конечно, изменились, но клиент забыл передать подрядчику новые пароли.

Через некоторое время все исправили и задачи наконец стали выполняться, таким образом решилась единственная критичная проблема проекта.

Результаты за месяц работ:

Выложили метатеги, прописали понятные URL для каждой карточки, настроили редиректы. И сразу же заметили динамику в Яндексе. Например, запрос «купить офисный стол» с 101 места в выдаче поднялся на 8. В данный момент заканчивается работа над визуальными изменениями сайта, подходят к концу последние этапы технической оптимизации.

Совет Rookee: Будьте внимательны при оформлении договора с хостингом. Вам должны предоставить доступ в личный кабинет. Проверьте адрес, по которому осуществляется вход, логин или имя аккаунта, пароль. Доступ к хостингу крайне важен, так как с помощью него осуществляется полный контроль информации на сайте.

Когда нужно быть сыщиками, а не сеошниками

Сайт доставки еды Sakura22 достался его владельцу вместе с бизнесом, который он купил 3 месяца назад. Что характерно — доступов к хостингу, домену и FTP у него не было. Специалистам Rookee предоставили только возможность попасть в админку сайта. При таком положении дел 7 из 8 самых важных доработок выполнить было невозможно. Можно было прописать метатеги и на этом завершить оптимизацию. Однако в Rookee решили иначе. Первым делом связались с хостингом — выяснилось, что факт владения бизнесом не доказывает владение сайтом, да еще и срок регистрации доменного имени подходит к концу.

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

Ситуацию спасло грандиозное расследование. SEO — это не всегда прямая работа с сайтом, иногда нужно быть настоящими сыщиками. Например, искать контактные данные в подвалах сайта по скрытым ссылкам, в админке расшифровывать кодовые названия предыдущих владельцев, связываться с этими ребятами и пытаться до них достучаться. Это помогло, владелец Sakura22 наконец получил все доступы, а эксперты Rookee со спокойной душой приступили к технической оптимизации.

Результаты за месяц работ:

Все эти перипетии с доступами притормозили работу, но даже по метатегам есть небольшие результаты. Буквально за два дня средняя позиция по Google поднялась с 72 на 59 место.

Совет Rookee: При покупке “готового сайта” обязательно осуществите переоформление домена, перенос файлов сайта и базы данных на хостинг покупателя, проверку работоспособности сайта, смену паролей пользователей на сайте, передачу сайта в партнерках, передачу пароля статистики и т.д. Обратись к профессионалам, которые осуществят контроль!

Выводы

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

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

Совет Rookee: Учитесь на чужих ошибках и используйте удачные решения в работе над своими проектами!


ссылка на оригинал статьи https://habr.com/post/424421/

Lisp со вкусом Pascal или 8501-й язык программирования

Некоторое время назад (года три) решил почитать учебник по Лиспу. Без всякой конкретной цели, просто ради общего развития и возможности шокировать собеседников экзотикой (один раз кажется, даже получилось).

Но при ближайшем рассмотрении Лисп оказался действительно мощным, гибким и как, ни странно, полезным в «быту». Все мелкие задачи автоматизации быстро перекочевали в скрипты на Лиспе, а так же появились возможности для автоматизации более сложной.

Здесь стоить отметить, что под «возможностью автоматизации» я подразумеваю ситуацию, когда суммарное время на написание и отладку программы меньше, чем время, затрачиваемое на решение той же задачи вручную.

Пол Грэм написал не одну статью и даже книгу о преимуществах Лиспа. На момент написания этой статьи Lisp занимает 33-е место в рейтинге TOIBE (в три раза мертвее мёртвого Delphi). Возникает вопрос: почему язык так мало распространён если он так удобен? Приблизительно два года использования дали несколько намёков на причины.

Недостатки

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

2. Отсутствие инкапсуляции
Понятие пакета хотя и существует, но не имеет ничего общего с package в Ada или unit в Delphi. Любой код может добавить что угодно в любой пакет (кроме системных). Любой код может извлечь что угодно из любого пакета, используя оператор ::.

3. Бессистемные сокращения
Чем отличается MAPCAN от MAPCON? Почему в SETQ, последняя буква Q? С учётом возраста языка можно понять причины такого состояния дел, но хочется языка немного почище.

4. Многопоточность
Этот недостаток косвенно относится к Лиспу и, в основном, касается используемой мной реализации — SteelBank Common Lisp. Стандартом Common Lisp многопоточность не предусмотрена. Попытка использования реализации, предоставляемой SBCL, к успеху не привела.

Отказываться от такого удобного инструмента жалко, но неудовлетворённость постепенно накапливается.

Поиск решения

Сначала можно зайти на Википедию на страницу Лиспа. Осмотреть раздел «Диалекты». Прочитать краткое введение к каждому. И осознать, что на вкус и цвет все фломастеры разные.

Если хочешь что-то сделать, нужно это делать обязательно самому
— Жан Батист Эммануэль Зорг

Попробуем создать свой правильный Лисп, добавив в него немного Ады, много Delphi и совсем каплю Оберона. Назовём полученную смесь Лися.

Основные концепции

1. Никаких указателей
В рамках борьбы с ПРОБЛЕМОЙ-1 все операции должны производиться путём копирования значений. По виду структуры данных в коде или при выводе на печать должны быть полностью видны все её свойства, внешние и внутренние связи.

2. Добавим модули
В рамках борьбы с проблемой-2 импортируем из Ады операторы package, with и use. В процессе, отбросим избыточно сложную схему импорта/затенения символов Лиспа.

(package имя-пакета (список экспортируемых символов) 	(реализации) 	(функций)) 

(with имя-пакета) ;поиск файла «имя-пакета.lisya» и импорт содержимого

(use имя-пакета)  ;аналогично, но символы импортируются без имени пакета 

3. Меньше сокращений
Наиболее частые и общеупотребительные символы всё равно будут с сокращениями, но преимущественно наиболее очевидные: const, var. Функция форматированного вывода — FMT требует сокращения, поскольку часто встречается внутри выражений. Elt — взятие элемента — просочился из Common Lisp и прижился, хотя необходимости в сокращении нет.

4. Регистронезависимые идентификаторы
Я считаю, что правильный язык (и файловая система) {$HOLYWAR+} должен быть регистронезависимым {$HOLYWAR-}, чтобы не ломать лишний раз голову.

5. Удобство использования с русской раскладкой клавиатуры
Синтаксис Лиси всячески избегает использования символов, недоступных в одной из раскладок. Нет квадратных и фигурных скобок. Нет #, ~, &, <, >, |. При чтении численных литералов правильными десятичными разделителями считаются как запятая, так и точка.

6. Расширенный алфавит
Одной из приятных черт SBCL оказался UTF-8 в коде. Возможность объявлять константы МЕДВЕДЬ, ВОДКА и БАЛАЛАЙКА значительно упрощает написание прикладного кода. Возможность вставлять Ω, Ψ и Σ делает формулы в коде наглядней. Хотя теоретически существует возможность использовать любые символы юникода, гарантировать корректность работы с ними сложно (скорее лень, чем сложно). Ограничимся кириллицей, латиницей и греческим.

7. Численные литералы
Это наиболее полезное для меня расширение языка.

10_000 ;разделители разрядов для удобочитаемости 10k ;десятичные приставки для целых и дробных чисел 10к ;русские десятичные приставки для минимизации переключений раскладки 10° 10pi 10deg 10гр ;не десятичные приставки 10π ;приставка pi в более эстетичном варианте 10+i10 ;литерал комплексного числа  10+м10 ;ещё раз комплексное число  10а10deg ;литерал комплексного числа в показательной форме с аргументом в градусах

Последний вариант мне кажется самым не эстетичным, но он самый востребованный.

8. Циклы
Циклы в Лиспе нестандартны и изрядно запутаны. Упростим до минимального стандартного набора.

(for i 5   	;повторить пять раз i = 0..4 	) (for i 1..6  	 ;повторить пять раз i = 1..5 	) (for i список  	 ;повторить для каждого элемента списка  	;допускается присваивание нового значения переменной цикла ) (for i (subseq список 2)  	 ;повторить для элементов списка начиная со второго элемента и до конца 	)

Переменная цикла за его пределами не видна.

(while условие 	)

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

(block 	:метка 	(goto :метка)) ;этот блок кода иногда зависает

10. Унификация областей видимости
В Лиспе есть два различных типа областей видимости: TOPLEVEL и локальная. Соответственно есть два разных способа объявления переменных.

(defvar A 1) (let ((a 1)) …)

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

(var A 1)

При необходимости ограничить область видимости используется оператор

(block  	(var A 1) 	(set A 2) 	(fmt nil A))

Тело цикла содержится в неявном операторе BLOCK (как и тело функции/процедуры). Все объявленные в цикле переменные уничтожаются в конце итерации.

11. Однослотовость символов
В Лиспе функции являются особыми объектами и хранятся в специальном слоте символа. Один символ может одновременно хранить переменную, функцию и список свойств. В Лисе каждый символ связан только с одним значением.

12. Удобный ELT
Типичный доступ к элементу сложной структуры в Лиспе выглядит так

(elt (slot-value (elt структура 1) 'слот-2) 3) 

В Лисе реализован унифицированный оператор ELT, обеспечивающий доступ к элементам любых составных типов (списков, строк, записей, массивов байт, хэш-таблиц).

(elt структура 1 \слот-2 3)

Идентичную функциональность можно получить и макросом на Лиспе

(defmacro field (object &rest f) 	"Извлекает элемент из сложной структуры по указанному пути. 	(field *object* 0 :keyword symbol \"string\") 	Каждый числовой параметр трактуется как индекс массива. 	Каждое ключевое слово трактуется как свойство в plist. 	Каждый символ (не ключевой) трактуется как функция доступа. 	Каждая строка трактуется как ключ в ассоциативном массиве." 	(if f 	(symbol-macrolet ((f0 (elt f 0))(rest (subseq f 1)))		 			(cond  				((numberp f0) `(field (elt ,object ,f0) ,@rest)) 				((keywordp f0) `(field (getf ,object ,f0) ,@rest)) 				((stringp f0) `(field (cdr (assoc ,f0 ,object :test 'equal)) ,@rest)) 				((and (listp f0) (= 2 (length f0))) 					`(field (,(car f0) ,(cadr f0) ,object) ,@rest)) 				((symbolp f0) `(field (,f0 ,object) ,@rest)) 				(t `(error "Ошибка форматирования имени поля")))) 		object))

13. Ограничение режимов передачи параметров подпрограмм
В Лиспе имеется, как минимум пять режимов передачи параметров: обязательные, &optional, &rest, &key, &whole и разрешена их произвольная комбинация. В действительности, большинство комбинаций дают странные эффекты.
В Лисе разрешено использовать только комбинацию из обязательных параметров и одного из следующих режимов на выбор :key, :optional, :flag, :rest.

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

Защищённые объекты всегда содержат критические секции для обеспечения атомарности операций. Вход в критические секции осуществляется автоматически — отдельных операторов для этого в языке нет. К защищённым объектам относятся: очередь сообщений, консоль и файловые дескрипторы.

Создание потоков возможно многопоточной функцией отображения

(map-th (function (x) …) данные-для-обработки) 

Map-th автоматически запускает количество потоков, равное количеству процессоров в системе (или в два раза больше, если у вас Intel inside). При рекурсивном вызове, последующие вызовы map-th работают в один поток.

Дополнительно есть встроенная функция thread, выполняющая процедуру/функцию в отдельном потоке.

;пример асинхронного исполнения (var поток (thread  длительные-вычисления-1)) (+ (длительные-вычисения-2) (wait поток))

15. Функциональная чистота в императивном коде
В Лисе есть функции для функционального программирования и процедуры для процедурного. На подпрограммы, объявленные с использованием ключевого слова function, налагаются требования отсутствия побочных эффектов и независимости результата от внешних факторов.

Нереализованное

Некоторые интересные возможности Лиспа остались не реализованными в силу низкого приоритета.

1. Обобщённые методы
Возможность выполнять перегрузку функций при помощи defgeneric/defmethod.

2. Наследование

3. Встроенный отладчик
При возникновении исключения интерпретатор Лиспа переключается в режим отладчика.

4. UFFI
Интерфейс для подключения модулей, написанных на других языках.

5. BIGNUM
Поддержка целых чисел произвольной разрядности

Отброшенные

Некоторые возможности Лиспа были рассмотрены и сочтены бесполезными/вредными.

1. Управляемая комбинация методов
При вызове метода для класса выполняется комбинация методов родителей и существует возможность изменять правила комбинации. Итоговое поведение метода представляется слабо предсказуемым.

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

3. Римский счёт
Лисп поддерживает систему счисления, которая устарела незадолго до его появления.

Использование

Приведу несколько простых примеров кода

(function crc8 (data :optional seed)     (var result (if-nil seed 0))     (var s_data data)      (for bit 8         (if (= (bit-and (bit-xor result s_data) $01) 0)             (set result (shift result -1 8))         (else             (set result (bit-xor result $18))             (set result (shift result -1 8))             (set result (bit-or result $80))))         (set s_data (shift s_data -1 8)))     result)

;поэлементное возведение списка в квадрат (map (function (x) (** x 2)) \(1 2 3))

;извлечение из списка строк, начинающихся с qwe и длиной более пяти символов (filter (function (x) (regexp:match x «^qwe...»)) список-строк)  ;но если строк много, а процессор шестиядерный, то лучше так (filter-th (function (x) (regexp:match x «^qwe...»)) список-строк)

Реализация

Интерпретатор написан на Delphi (FreePascal в режиме совместимости). Собирается в Lazarus 1.6.2 и выше, под Windows и Linux 32 и 64 бита. Из внешних зависимостей требует libmysql.dll. Содержит около 15_000..20_000 строк. Имеются около 200 встроенных функций различного назначения (некоторые перегружены по восемь раз).

Хранится здесь

Поддержка динамической типизации выполнена тривиальным образом — все обрабатываемые типы данных представлены наследниками одного класса TValue.

Важнейший для Лиспа тип — список является, как и принято в Delphi, классом, содержащим динамический массив объектов типа TValue. Для данного типа реализован механизм CopyOnWrite.

Управление памятью автоматическое на основе подсчёта ссылок. Для рекурсивных структур выполняется подсчёт всех ссылок в структуре одновременно. Освобождения памяти запускается сразу при выходе переменных из области видимости. Механизмы отложенного запуска сборщика мусора отсутствуют.

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

Каждый оператор или встроенная функция Лиси реализован как метод или функция в коде интерпретатора. Выполнение скрипта осуществляется путём взаимно-рекурсивного вызова реализаций. У кода интерпретатора и скрипта общий стек вызовов.

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

Особую сложность представляет собой реализация оператора присваивания (set) для элементов структур. Непосредственное вычисление указателя на требуемый элемент приводит к риску появления висячих ссылок, поскольку синтаксис Лиси не запрещает модификацию структуры в процессе вычисления требуемого элемента. Как компромиссное решение реализован «цепочечный указатель» — объект, содержащий ссылку на переменную и массив числовых индексов для указания пути внутри структуры. Такой указатель так же подвержен проблеме висячих ссылок, но в случае сбоя генерирует осмысленное сообщение об ошибке.

Инструменты разработки

1. Консоль

2. Текстовый редактор
Оборудован подсветкой синтаксиса и возможностью запуска редактируемого скрипта по F9.

Заключение

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


ссылка на оригинал статьи https://habr.com/post/424447/

Календарь тестировщика. Оптимизируй тесты

И снова в нашей ленте «Календарь тестировщика». В этом месяце Марина Третьякова, тестировщик проекта Контур.Поставки, расскажет об оптимизации тестов. Марина разберет конкретные проблемы и способы их решения, а также посоветует, как оптимизировать свои тесты и сократить время на тестирование.

Прежде всего давайте разделим всё тестирование по степени автоматизации, чтобы в дальнейшем рассматривать каждый тип более детально.

По степени автоматизации тесты делятся на:

  1. Ручные.
  2. Автоматизированные.
  3. Автоматические (без участия человека, на данный момент – скорее миф нежели реальность).

Подход к оптимизации тестов напрямую зависит от степени их автоматизации.

Оптимизации, применимые ко всем видам тестов

Тестирование включает в себя этапы:

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

Считается, что больше всего времени у тестировщиков отнимает ручная регрессия. Однако, в большинстве случаев это не так. Как минимум, не стоит это утверждать, пока проблема не измерена и не доказана.

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

Проблемы:

1. Долгая подготовка тестируемой системы

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

  • Долгая относительно чего?
  • Кто занимается этой подготовкой (тестировщики, программисты…)?
  • Сколько раз при желании можно за рабочий день подготовить тестируемую систему? Соответствует ли это число потребностям тестирования?
  • Какой этап в подготовке самый долгий и почему?

Чтобы найти причину этой проблемы, важно задать правильный вопрос.
Рассмотрим примеры:

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

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

Долгий процесс «разлития» исходников по «виртуалкам» на тестовом стенде для дальнейшей компиляции и раскатки
Вероятная проблема: сетевое взаимодействие.
Правильный вопрос: долгий относительно чего (сбора на локальной машине, сбора в локальной сети)?
Решение: тестовый стенд и то место, где лежат исходники, должны находиться в одной сети, чтобы минимизировать сетевое взаимодействие.

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

2. Долгий сбор и анализ результатов

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

  • Долгий относительно чего?
  • Из каких этапов состоит процесс сбора и анализа результатов? Какой именно этап самый долгий и почему?
  • Кто анализирует результаты?
  • Кто принимает решение о релизе и на основании чего? Сколько тратит времени на принятие решения?

Например:
Результаты тестирования оформляются по шаблону, оформление по шаблону отнимает большУю часть времени при тестировании.

Решение (спасибо, Кэп!): отказаться от заполнения результатов по шаблону либо создать более легкий для заполнения шаблон. Потребуется договориться с командой и узнать у тех, кто читает эти результаты (а читают ли их?), действительно ли есть потребность именно в таком шаблоне (риск – писать «в стол» результаты тестирования).

Оптимизации, применимые к ручным тестам

Эти тесты можно разделить на два больших класса:

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

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

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

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

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

  1. вручную через UI,
  2. вручную через API,
  3. с помощью запуска автотестов, тогда данные будут побочным эффектом этих тестов,
  4. автоматизированно через скрипты/утилиты/самописные инструменты через API или UI.

Если вы никогда не задумывались, сколько времени у вас занимает ручная подготовка тестовых данных, то может пора это измерить? И окажется, что гораздо эффективнее использовать, как минимум второй, а лучше 3-й и 4-й подходы.

Оптимизации, применимые к автоматизированным тестам

Проблема подготовки тестовых данных здесь стоит острее, нежели при ручном тестировании. Подготовка тестовых данных должна быть:

  1. быстрой,
  2. устойчивой к изменениям дизайна/верстки,
  3. устойчивой к возможным параллельным запускам тестов,
  4. устойчивой к изменениям внутренней архитектуры системы.

Желательно, чтобы подготовка данных не требовала дополнительных навыков и времени при реализации решения.

Тестовые данные автоматизированно можно подготовить:

  1. через UI,
  2. через API или HTTP-запросы,
  3. через запросы к базе данных.

Рассмотрим плюсы и минусы этих подходов подробнее в таблице:

Подготовка тестовых данных через API или HTTP-запросы по совокупности плюсов и минусов является самой оптимальной.

Есть ряд наиболее распространенных оптимизаций, применимых к тестам, проводимым автоматизированно:

Параллельность тестов

Если одной из проблем тестов является именно время их прохождения, при этом есть вычислительные ресурсы, можно распараллелить и выполнять их в одном из трех режимов параллельности:

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

Удаление старых тестов

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

Применение техник тест-дизайна для оптимизации наборов тест-кейсов

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

Перенос существующих тестов и проверок на другой уровень

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

Правильная декомпозиция тестов по уровням “модульные — интеграционные — системные”

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

Правильным будет в данном случае разделить сначала тест на три подсценария: выбор товара, добавление товара в корзину, оформление заказа. Каждый сценарий разделим на более атомарные проверки.
Например: “открытие магазина — отображение разных категорий товара для выбора” — один тест; “выбор категории из разных категорий товара” — другой тест. Каждую проверку рассматриваем более детально и определяем, какого уровня тесты для нее нужны, предыдущий пример может подсказать, какого типа тесты лучше сразу оформлять как модульные.

Популярная схема связей тестируемой и тестирующей систем при автоматизированном тестировании web-приложений:

Для оптимизации автоматизированного тестирования web-приложения целесообразно рассматривать оптимизацию каждого взаимодействия в описанной схеме.

Для простоты рассмотрим оптимизации некоторых взаимодействий:

1) Взаимодействие “test-cases — browser — database”
Использование API не только для подготовки данных для теста, но и для проведения ряда шагов в тесте.

Например, если цель – проверить UI в конце длинной цепочки действий, то вовсе не обязательно все действия проводить через UI. Ведь если посередине цепочки в UI что-то поломалось, тест так и не дойдет до конца и целевой проверки. Тестировщик так и будет гадать, а если починят это сломанное звено цепочки, то всё, что после него работает ли? Если в данном случае на протяжении всей цепочки кроме последнего действия использовать API, то при UI поломке любого звена тестировщик будет знать, будет ли работать система так, как задумано, если разработчики починят сломавшееся звено.

2) Взаимодействие “test-cases — SeleniumWebDriver — browser”.

  • Закрытие лишних вкладок по завершению теста, вместо закрытия браузера.
    На моем проекте данная оптимизация помогла сэкономить 10 минут в прогоне UI тестов (вместо 1ч.10 мин. тесты стали проходить за 1ч.). Данная оптимизация связана с логикой работы SeleniumWebDriver, который используется на проекте – у него очень долгая подготовка открытия браузера, а вот закрытие вкладок происходит практически мгновенно.
  • Оптимизация кэша приложения тестируемой системы, чтобы тесты проходили быстрее.
  • Использование headless браузеров, чтобы не было затрат на рендеринг элементов веб-страниц.

В заключение

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

И еще раз хотелось бы повториться: не ищите рутинные тесты, ищите рутинные задачи, и автоматизируйте их!


ссылка на оригинал статьи https://habr.com/post/424349/

Перевод статьи Нила Форда «Микросервисы как эволюционная архитектура»

Мы подготовили перевод статьи Нила Форда, системного архитектора и идейного вдохновителя компании ThoughtWorks, которая занимается разработкой программных средств для автоматизации процессов тестирования и развертывания ПО.
Нил – признанный эксперт в области разработки программного обеспечения, работающий на стыке гибкого проектирования и системной архитектуры. Он является автором многочисленных статей, книг, десятков видео-презентаций, выступает с докладами на ведущих конференциях разработчиков. Его работы вы можете посмотреть на сайте nealford.com.

Микросервисы как эволюционная архитектура

Микросервисная архитектура стремительно завоевывает мир. В марте издательская компания O’Reilly организовала свою первую конференцию по архитектуре программного обеспечения (O’Reilly Software Architecture Conference). И почти 60% докладов были посвящены тем или иным аспектам использования микросервисов. Почему именно этот архитектурный стиль вдруг стал таким популярным?

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

Эволюционная архитектура

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

Микросервисная архитектура полностью соответствует этой идее благодаря тому, что в ней ограниченные контексты (Bounded Context), логически выделенные в соответствии с Предметно-ориентированным проектированием (Domain Driven Design) Эрика Эванса, реализуются как физически раздельно развертываемые компоненты. Это разделение достигается за счет внедрения практик DevOps, таких как выделение виртуальных машин, тестирование и автоматизированное развертывание. Поскольку каждый сервис отделен от всех остальных сервисов (на структурном уровне), замена одного микросервиса на другой происходит так же легко, как перестановка кубиков Лего.

Особенности эволюционной архитектуры

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

Модульность и связанность

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

[Связь между классами (точки по периметру) в большом комке грязи из неназванного клиентского проекта.]

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

Организация вокруг бизнес-возможностей

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

Эксперименты

Проведение экспериментов — одно из существенных преимуществ, которые эволюционная архитектура дает бизнесу. Возможность легкого внесения в приложения небольших изменений обеспечивает применение таких распространенных практик непрерывного развертывания, как A/B-тестирование, тестирование на ограниченной группе пользователей (Canary release) и других. Микросервисные архитектуры нередко выстраиваются на основе маршрутизации обращений к сервисам, благодаря чему создается возможность использования нескольких версий сервиса в рамках целой экосистемы. Это в свою очередь открывает широкие возможности для экспериментов и изменения существующей функциональности. В конечном счете при разработке бизнес-приложений меньше времени тратится на обсуждение планов и бэклога, а разработка ведется в основном в режиме быстрой проверки гипотез.

Принципы эволюционной архитектуры

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

Функции приспособленности (fitness function)

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

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

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

Внимание на болевые точки

Многие методы работы, применяемые в процессе непрерывной поставки ПО и разработки эволюционирующей архитектуры, основываются на принципе «внимание на болевые точки», сформулированном сообществом eXtreme Programming. Когда в проектной работе возникают моменты, которые могут стать источниками проблем (болевыми точками), необходимо как можно раньше обратить на них внимание. Это поможет заблаговременно выявить потенциальные проблемы и устранить их в рабочем порядке. Такие обычные практики непрерывной поставки, как конвейер развертывания, автоматическое выделение виртуальных машин и перенос баз данных, в случае проектирования эволюционной архитектуры значительно упрощают устранение болевых точек на этапе внесения изменений.

Момент принятия решения

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

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

Заключение

Архитекторы программного обеспечения должны разъяснять принимаемые решения об устройстве разрабатываемых систем, как правило, с помощью разного рода диаграмм. Разработчики архитектуры нередко попадают в ловушку, представляя архитектуру ПО как уравнение, которое они должны решить. Множество коммерческих инструментов, предлагаемых архитекторам ПО, позволяют формально описать архитектуру в виде квадратиков, линий и стрелок. Хотя такие диаграммы могут быть полезны, они предлагают лишь двухмерное отображение, снимок идеального мира, но мы живем в четырехмерной реальности.
Чтобы наполнить такую двухмерную диаграмму жизнью, необходимо ее конкретизировать. Метка ORM на двухмерной диаграмме становится Hibernate v4.2.17, делая представляемый мир трехмерным. Когда у вас будет план по ее внедрению в производство и обновления через полгода до неизбежной версии Hibernate v4.3.0.1, вы будете готовы к четырехмерному миру. Многие архитекторы не понимают, что статическое представление архитектуры имеет короткий срок использования. Вселенная программного обеспечения существует в состоянии потока, она динамичная, а не статична. Архитектура — это не уравнение, а скорее моментальный снимок длящегося процесса.

Практики непрерывной поставки ПО и DevOps показали проблемы, растущие из непонимания усилий, которые нужны для реализации и поддержки архитектуры. Реализация архитектуры — это лишь первый шаг. Архитектура остается абстракцией до тех пор, пока она не приведена в действие. Другими словами, о жизнеспособности любой архитектуры в долгосрочной перспективе можно судить только тогда, когда вы не только реализовали, но и хотя бы один раз модифицировали ее. И может быть, сумели справиться с неожиданностями на этом пути.
Понимание архитектором ПО операционных возможностей чрезвычайно важно для разработки эволюционной архитектуры. Эволюционное развитие архитектуры влияет на особенности ее реализации, и поэтому их необходимо учитывать в процессе доработки. Требования, предъявляемые процессом непрерывной поставки к архитектуре, направлены на то, чтобы улучшить ее визуализацию и упростить внесение изменений. Тем самым непрерывная поставка обеспечивает расширение возможностей эволюционной архитектуры.

19 ноября Нил Форд приезжает в Москву с мастер-классом по созданию эволюционной архитектуры ПО.


ссылка на оригинал статьи https://habr.com/post/424445/