Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1457 сообщений
Cообщения с меткой

инфраструктура - Самое интересное в блогах

Следующие 30  »
lj_zyalt

Самая плохая велодорожка в мире

Понедельник, 23 Мая 2016 г. 10:05 (ссылка)

Я был уверен, что меня невозможно удивить, особенно городской инфраструктурой. Ну чего я не видел? На прошлой неделе в Кишиневе я понял, что не видел велодорожки! Того, что сделали молдаване, не делал еще никто.


Кишиневская велодорожка по праву занимает первое место в рейтинге самых плохих и нелепых велодорожек в мире! Смотрите сами...



01. Нарисовать ее решили просто краской на тротуарах.


02. Авторы не подумали над тем... Блин, да они вообще ни над чем не подумали! Вот что бывает, когда в голове вместо мозгов мамалыга...


03. Здесь под велодорожку отдали одну сторону пешеходного бульвара... А-ха-ха-ха!


04. Но самое смешное начинается здесь. Ну а что? "Насяльника сказал сделать 2 метра от бордюра – мы и сделали!"


05. Это очень смешно.


06. Пересечение с дорогой


07. Я вначале думал, что это линия, показывающая туристический маршрут. Знаете, иногда в городах делают такие.


08. Если что, велодорожка слева...


09. Да, в половине случаев на ней парковка.


10.


11. Велодорожка идет через мост.


12. Полоса препятствий


13. Что-то пошло не так.


14.


15. Самое удивительное, что по этой велодорожке стараются ездить велосипедисты.


16. Молдавский велосипедист должен страдать.


17.


18. Теперь вы видели всё.








Как правильно делать велодорожки
Город для людей на велосипедах Вредные советы для Москвы







Благими намерениями выложена велодорожка в ад
Декоративная велодорожка на Пятницкой

В Москве завелся вредитель...



http://varlamov.ru/1734354.html

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Судный день: К чему приводят скрытые ошибки асинхронной обработки данных при росте нагрузки

Суббота, 14 Мая 2016 г. 10:50 (ссылка)





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



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



Все пропало



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



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



Служба поддержки была поднята по тревоге. Предстояло максимально быстро найти и устранить проблему.



Горячий день



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



Это не помогло — абонентам легче не стало. Клиент тем временем начал паниковать: поток возмущенных звонков «я заплатил, но ничего не работает» начал заваливать его колл-центр. Разбирательство продолжилось.



На сервере RADIUS-авторизации, который за несколько дней до этого переехал на новое «железо», инженеры обнаружили сильнейшее замедление работы. Быстро выяснилось, что оно приводило к тому, что в БД сервера авторизации содержались неактуальные данные о пользовательских профилях — именно поэтому биллинг ошибочно открывал доступ в интернет одним абонентам и закрывал его тем, кто оплачивал услуги вовремя. Однако причина столь драматического падения производительности оставалась неясной.



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



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



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



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



Лирическое отступление: Когда город засыпает



Итак, в ночь на 1 апреля биллинг начал генерировать новые данные для абонентских профилей на замену старым — если абонент не оплатил услугу, то нужно было отобрать у него доступ к ней. На этом шаге модуль provisioning сгенерировал большое количество новых профилей и асинхронно отправил их во внутреннюю очередь сообщений Oracle. Поскольку напрямую с очередями Oracle работать извне с нашим стеком технологий неудобно, для их дальнейшей передачи используется «прослойка» в виде брокера сообщений Apache ActiveMQ, к которому подключается RADIUS-сервер, записывающий данные в MongoDB.



Биллинг должен отправлять данные об измененных абонентских профилях в строгом порядке. Чтобы порядок соблюдался и не происходило «путаницы» профилей на отключение и подключение, в системе реализован специальный процесс, который выбирает данные из очереди ActiveMQ и записывает их в MongoDB.



Приходит понимание



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



Ранее иногда случались случаи потери связи RADIUS-сервера с ActiveMQ — на такой случай мы предусмотрели функциональность восстановления соединений. Для детектирования случаев потери связи был реализован специальный механизм, использующий протокол STOMP — в нем есть настройка передачи heartbeat-пакетов. Если такой сигнал не получен, то соединение считается утерянным и принудительно переустанавливается.



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



Сообщения из ActiveMQ всегда извлекаются в том же потоке исполнения, который записывает данные в профили абонентов. Извлечение и запись — то, что он делает по порядку, и если запись задержалась, то поток не может «достать» следующий пакет. И если в нем содержался heartbeat, то он не будет получен — и другой поток, который проверяет наличие таких пакетов, будет считать соединение потерянным и попытается его переустановить.



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



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



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



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



Поиск причин



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



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



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



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



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



Второй процесс — предотвращение установления новой сессии отключенным абонентом. Для этого в независимую базу данных авторизационного сервера с пользовательскими конфигурациями нужно реплицировать данные из provisioning-модуля «Гидры». Это позволяет всем частям системы знать о том, что определенных абонентов обслуживать сейчас не нужно.



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



Вторая причина — желание сэкономить на инфраструктуре и отказ от разумного разнесения сервисов. Для биллинга был закуплен менее мощный сервер, чем было необходимо. Четыре года он отработал без проблем, однако объём данных в БД рос, кроме того, на сервер постепенно «навешивались» требовательные к ресурсам дополнительные сервисы (внешняя отчетная система на Java-машине, новый модуль provisioning также с использованием Java-машины и т.д.), а рекомендации инженеров, говоривших о необходимости разнесения сервисов, откладывались в долгий ящик с аргументом «работает же».



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



Незадолго до 1 апреля наконец удалось получить отдельный сервер для авторизационной БД с профилями абонентов. Как выяснилось позже, RAID-массив на этом сервере оказался дефектным, и на нем авторизация при определенном уровне нагрузки тормозила еще сильнее, чем на старом «железе». Ни на одной из более чем 100 других инсталляций «Гидры» эта ошибка не проявлялась из-за того, что в нормальных условиях сервис авторизации работает быстро и ресурсов хватает с большим запасом.



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



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



Предотвращение проблем в будущем



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


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

  • Кроме того была увеличена частота отправки heartbeat-пакетов — вместо пяти секунд время увеличилось до нескольких минут. В дополнение к механизму heartbeat соединение к брокеру сообщений стало устанавливаться с опцией keepalive с небольшими интервалами проверки активности соединения (несколько десятков секунд против пары часов, устанавливаемой операционной системой по умолчанию).

  • Также производились тесты, в ходе которых при отправке сообщений случайным образом перезапускались разные модули системы. В ходе одного из таких тестов какая-то часть данных все равно оказывалась потерянной. Тогда был заменен сам «движок» базы данных MongoDB — перешли на использование WiredTiger. Мы планировали сделать это раньше, но по случаю тестов решили совместить переезд.



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



Кроме того, по рекомендациям инженеров техподдержки «Латеры» сервисы системы были разнесены на разные серверы (деньги на них быстро нашлись). Это удалось успеть сделать до 1 мая — следующего дня массовых биллинговых операций.



Главный урок



Тревожные «звоночки», сигнализирующие о возможных проблемах, звучали и в марте, но выявить их до наступления планового всплеска активности не удалось. Если бы этого всплеска не было, или он произошел бы в другом месте — не на «тормозящем» RADIUS-сервере с максимальной скоростью последовательной записи 5 МБ/сек, то с высокой долей вероятности инженерам удалось бы локализовать проблему в апреле. Им не хватило буквально нескольких дней.



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



Другие технические статьи от «Латеры»:







Original source: habrahabr.ru.

https://habrahabr.ru/post/283548/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
stertenorva

Завершились испытания наземной инфраструктуры ГЛОНАСС

Воскресенье, 09 Мая 2016 г. 02:02 (ссылка)

Испытания наземной инфраструктуры системы ГЛОНАСС завершены, подписан акт, но совместное решение Минобороны и Роскосмоса еще не готово, сообщил гендиректор компании «Российские космические системы» (РКС) Андрей Тюлин. «Испытания по наземной инфраструктуре системы ГЛОНАСС

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт использования IaaS крупными (и не очень) компаниями

Четверг, 05 Мая 2016 г. 16:10 (ссылка)





Мы в «ИТ-ГРАД» стараемся рассказывать в своем блоге на Хабре об облачных технологиях и ИТ-инфраструктуре. На прошлой неделе мы представили технико-экономическое обоснование для внедрения облачных технологий на уровне виртуальной инфраструктуры.



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




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



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



На сегодняшний день в IaaS-облако «ИТ-ГРАД» вынесена большая часть сервисов FRANMER, среди которых выделяются распределенная база 1С, содержащая информацию о товарах, заказах и клиентах, и виртуальный call-центр. Главным преимуществом облачного call-центра является то, что все входящие звонки обрабатываются цифровой АТС. Благодаря этому можно оперативно получить данные звонящего из базы 1С (имя, фамилию, отчество); в этом случае менеджеры FRANMER видят детали всех входящих звонков.



Поскольку FRANMER располагает большим количеством дилерских офисов в разных городах, всем сотрудникам компании необходим централизованный доступ к единой базе 1С. Данная функциональность и была реализована за счет переноса базы 1С в IaaS-облако «ИТ-ГРАД».







Если обратиться к статистике, то станет понятно, что сегодня компании все чаще смотрят в сторону «облаков»: начиная с 2014 года популярность облачных технологий возрастает на 44% ежегодно, а суммарная стоимость оборудования, которое заменит облачная инфраструктура к 2018 году, оценивается в $79,1 млрд.



При этом одни организации переводят ИТ-инфраструктуру в облако полностью, другие – лишь её часть. Сеть универсамов «АБК» пошла по второму пути, осуществив перенос в облако провайдера виртуальных серверов с системой ServiceDesk.



«Мы пришли к выводу, что система ServiceDesk является непрофильным активом для компании и целесообразнее с экономической и технической точки зрения вынести ее в облако, – комментирует Дмитрий Зотов, руководитель отдела системного администрирования «АБК». – В силу того, что обслуживать решение собственными силами на собственной площадке оказалось дороже, чем использовать ресурсы IaaS-провайдера, который на этом профилируется, перевели сервис на облачную площадку».







На данный момент базовая архитектура компании, которая включает Active Directory, почтовые и файловые сервисы и системы учета, работает «на месте» и контролируется ИТ-отделом компании. Однако в ближайшем будущем руководство «АБК» планирует перенести все эти сервисы в облако, в частности, в облако «ИТ-ГРАД».



Сеть универсамов «АБК» наглядно демонстрирует одну из стратегий перехода в облако: перенести один сервис «на пробу», а затем уже подтягивать остальные. Такой подход практикуют многие компании.



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



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







При такой нагрузке поддерживать собственную инфраструктуру и наращивать мощности собственных ЦОД с каждым годом становится все труднее. Облако же позволяет оперировать тысячами виртуальных серверов и петабайтами дискового пространства. Сегодня Netflix – это одна из крупнейших компаний, работающих с виртуальной инфраструктурой. Единственное, что Netflix решила не переводить в облако, – это сети доставки контента, разворачиваемые на стороне отдельных сервис-провайдеров.



Система доставки контента кеширует видео на сайтах провайдеров, что улучшает производительность стриминговых сервисов. Для этого Netflix устанавливает собственные серверы на стороне интернет-провайдера и контролирует сеть за пределами облачной экосистемы облака. Сейчас frontend-сервисы Netflix работают на веб-серверах Tomcat и nginx, количество которых варьируется от 500 до 1000 в зависимости от запросов клиентов. Также компанией используются серверы баз данных NoSQL Cassandra, высокая производительность которых обеспечивается за счет системы распределенного кэширования объектов.







На изображении выше показано, что переход на облачные технологии осуществлялся постепенно в течение нескольких лет. По словам вице-президента по разработке облачных решений Netflix Юрия Израилевского (Yury Izrailevsky), «переезд в облако оказался тяжелой работой».



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


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



Совет второй: стоит помнить, что переезд в облако – это не просто перенос приложений. Нужно обязательно пересмотреть процессы и модель финансирования и не забывать про решения Agile, Lean и DevOps. Еще будет полезно использовать конфигурационные инструменты управления, такие как Puppet или Chef, и инструменты интеграции и развертывания Jenkins и Travis CI.



И, наконец, третий совет: помните, что, перемещая приложение в облако «как есть», вы тянете за ним существующие проблемы. Из-за этого вам в дальнейшем потребуется вносить изменения в архитектуру. Подумайте о движении в сторону микросервисов и использовании инструментов для эффективной работы с данными (например Redis, Memcached и MongoDB).



Переезд в облако не должен проходить спонтанно, особенно если речь идет о переносе сотен различных сервисов и тысяч компонентов. Здесь необходима стратегия поэтапной, плавной и безболезненной миграции. Спешка в этом вопросе – не помощник.



P.S. Наши другие материалы по теме:







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281809/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
lj_colonelcassad

Строительство Керченского моста к маю 2016

Понедельник, 02 Мая 2016 г. 13:47 (ссылка)



Свежие видео конца апреля 2016 года, где можно увидеть текущий прогресс строительства Керченского моста, который как сообщают украинские "эксперты" никогда не будет построен.









О параметрах Керченского моста:

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

Утвержденный проект предполагает два параллельных моста с независимым друг от друга автодорожным и железнодорожным движением. Сооружения находятся на расстоянии 50 м друг от друга. Пролетные строения – балочные с расчетными пролетами 55 м и 64 м. Опоры – из монолитного железобетона с ростверками, возвышающимися над водой. Фундаменты опор – свайные и в зависимости от конкретных геологических условий на участках выполнены в виде железобетонных буронабивных, забивных или металлических трубчатых свай. Фарватер Керчь-Еникальского канала перекрывается арками с расчетными пролетами 227 м. Здесь автодорожный и железнодорожный мосты будут стоять на объединенных мощных опорах.

По словам Романа Старовойта, в настоящее время построено уже 10 опор будущего моста. В работе находятся еще 69 опор на различных участках строительства. Погружено уже более 600 свай разного типа, ведется забивка еще 115 свай. На данный момент на стройплощадки поставлено более 4,3 млн тонн строительных грузов. Задействованы 25 тяжелых строительных кранов, 10 плавкранов, 130 единиц дорожно-строительной техники, другое оборудование.

Работы на стройплощадке ведутся в полном соответствии с графиком. Строительство моста будет производиться на 8 участках одновременно, что обеспечит открытие автомобильного движения в рабочем режиме в максимально короткие сроки – уже в декабре 2018 года. В 2019 году будет открыто движение поездов.

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

http://www.kerch.com.ru/articleview.aspx?id=56899 - цинк

О условиях труда на примере набираемой вахты из Омска (жалко не пишут размер зарплаты):

Требуются плотники-бетонщики и монтажники м/к и ж/б конструкций, электро-газосварщики с опытом работы а также разнорабочие.
Работа на строительстве Керченского моста, который соединит Россию и Крым. Мост пройдёт между Керченским и Таманским полуостровами через остров Тузла и Тузлинскую косу.
Вахта 2/1 мес.(по договору, возможны более длинные вахты). Трудоустройство согласно ТК РФ, предоставление полного соц.пакета и соц.гарантий, мед.страховка за счет компании. Запись в трудовую книжку со второго месяца. Проживание и питание предоставляются бесплатно. Стабильная заработная плата без вычетов на счет Сбербанка.
Отправка комплексной бригадой в середине мая. Первый проезд 50% оплачивает соискатель, в дальнейшем за счет предприятия. Формирование бригады происходит в г. Омске.


https://www.avito.ru/omsk/vakansii/trebuyutsya_rabochie_na_kerchenskiy_most_vahta_727036416 - цинк

А ниже про зарплаты и условия для строителей из Керчи:

От подрядчика строительства транспортного перехода через Керченский пролив - компании "СГМ-Мост" - в центр занятости Керчи поступили первые 146 вакансий. Всего же принять участие в возведении моста смогут несколько тысяч человек.
По словам директора территориального отделения ГКУ "Центр занятости населения" в Керчи Вадима Кутузова, компания готова трудоустроить по 50 монтажников железобетонных конструкций и газоэлектросварщиков, 25 инженеров, по четыре машиниста и диспетчеров. Предлагаемая зарплата - от 18 до 40 тысяч рублей. Требования работодателя к соискателям: наличие профильного образования и опыт работы.


http://rg.ru/2016/03/21/reg-kfo/vakansii-na-stroitelstve-kerchenskogo-mosta.html - цинк

Так же можете почитать вот здесь по ссылке http://kerch-most.ru/zapolni-anketu-i-poluchi-rabotu.html запросы желающих принять участие в строительстве моста за последний год, где можно отметить наличие людей строивших мост на остров Русский и объекты Сочинской Олимпиады.

Плюс видео о строительстве железнодорожных подходов со стороны Крыма (нашел у periskop)



Плюс там есть интересный комментарий насчет ж/д строительства по Крыму.

Общался с сотрудниками ДКРС РЖД (ДКРС - Дирекция по комплексной реконструкции железных дорог и строительству объектов). Они в т.ч. ездили ознакамливаться с инфраструктурой коллег из КЖД в прошлом году.
Тезисно по желдор части и "хотелкам":
1) строительство подходов, что со стороны Крыма, что со стороны Тамани ведётся по отдельной бюджетной статье и в стоимость мостовой переправы не включены.
Тендер по подъездным путям к мосту на стороне Краснодарского края:
Автодорожная часть, строительство: http://zakupki.gov.ru/epz/order/notice/ea44/view/common-info.html?regNumber=0318100051215000185
Автодорожная часть, проектирование: http://zakupki.gov.ru/epz/order/notice/ok44/view/common-info.html?regNumber=0318100051214000036
Технологическое подсоединение тяговых подстанций в Тамани: http://zakupki.gov.ru/epz/order/notice/ep44/view/common-info.html?regNumber=0373100096715000019
По железнодорожной части был у РЖД тендер: http://tender.rzd.ru/tender/public/ru?STRUCTURE_ID=4078&layer_id=4040&refererLayerId=4893&id=84187
Со стороны Крыма - ни одного тендера как и видимой строительной движухи. С нашей стороны уже проложена 2-х путка до будущей ст. Портовая и видны заделы под 4-х полосную автодорогу (дорога примыкания к М25).
2) То что сказали точно сотрудники КЖД коллегам из РЖД, не планируется строить новых дорог (подъездные пути к Керченскому мосту не в счёт), до 2020 г. точно. Так что если найдётся дурак, который вместо самолёта на Симферополь поедет на ж.д., то в будущем катание по крюку Багерово-Владиславовка-Джанкой-Остряково гарантировано. Ходили всякие слухи, что могут построить спрямление, но на это средств нет. Ориентировочно требовалось порядка 80 млрд. руб. Да и все равно крючок будет, но поменьше. Гористая местност как никак и напрямую на Симферополь не выйти: http://www.raster-maps.com/images/maps/rastr/ukraine/crimea/crimea_5.gif
3) Пока в планах довести электрификацию до примыкания (ст. Багерово), Багерово-Джанкой останется неэлектрифицированным участком временно. Сначала предлагалось довести электрификацию от разъезда 9 км-Юровский-Вышестеблиевская-Портовая, но потом решили, что и на мосту надо сразу провести электрификацию, иначе потом будет большой геморрой, чтобы это сделать. С выделением многосуточных окон. Как никак 38 км ж.д. полотна в однопутном исчислении! Для такого расстояния в режиме окна быстро опоры не поставить...
4) В будущем планируется по ст. Джанкой сделать станцию стыкования, т.е. планы по переводу на переменный ток переиграны, ибо нужно много денежных ресурсов. Не готовы сейчас в это вкладывать. В итоге у нас появится 2-я островная электрификация на постоянном токе после Горячий Ключ/Белореченская-Туапсе-Адлер.


http://periskop.livejournal.com/1558536.html - цинк

Плюс ролик Росавтодора про постройку автомобильных подходов к Керченскому мосту со стороны Тамани.



Плюс стоит отметить, что в первой половине мая должен состоятся запуск уже 4-й нитки энергомоста, которая так же будет запущена с опережением графиков, что вкупе с уже введенными в строй ветками позволит совершенно безболезненно дожить до постройки Севастопольской и Симферопольской ТЭС, которые значительно повысят внутреннюю генерацию электроэнергии на полуострове. В Керчи в связи с работами по подключению 4-й нитки возможны отключения света. У нас, после ввода в строй 3-й ветки и окончания ремонтных работ, свет ни разу не отключали, освещение в вечернее время есть, троллейбусы ходят. Лепота.

http://colonelcassad.livejournal.com/2732556.html

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сценарии применения бесплатных инструментов Veeam для разработки и тестирования в Microsoft Azure

Среда, 27 Апреля 2016 г. 10:23 (ссылка)

Мы продолжаем рассказывать про решения независимых разработчиков, которые представлены на облачной платформе Azure и в Azure Marketplace. Сегодня о сценариях применения бесплатных инструментов компании Veeam, представленных в Azure Marketplace, рассказывает Александр Ширманов – R&D Director в Veeam. Вы всегда можете найти больше историй по ссылке на Хабре. – Владимир Юнев, Microsoft
Сегодня я хочу разобрать несколько сценариев использования публичного облака, продемонстрировав, как с их помощью можно выполнять те виды работ, которые до сих пор откладывались «в долгий ящик».



Я возьму такой пример инфраструктуры: имеется некоторый программный продукт, приложение, над которым постоянно трудятся инженеры (естественно, с целью довести его до совершенства). Основными компонентами являются:




  • сервер баз данных (Backend)

  • «среднее звено», т.е. сервис, выполняющий основные рабочие задачи (Middle-Tier)

  • веб-сайт, с которым непосредственно работают пользователи (Front-Tier)







Рис.1



Раньше для работы над продуктом нужно было развернуть как раз 3 виртуальные машины – по одной для каждого из компонентов. Но продукт совершенствуется, и каждый из компонентов теперь может включать несколько ролей – так, например, веб-сайт теперь задействует не одну, а несколько ВМ, и, соответственно, требует балансировки нагрузки (Load balancer). Нагрузка в «среднем звене» также распределяется. Ну и сервер баз данных теперь использует SQL Server AlwaysOn Availability Groups. В итоге инфраструктура, с которой работают инженеры, приобретает вид, показанный на рисунке 2.





Рис. 2



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

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



1. Создание инфраструктуры для разработки, тестирования и проверки качества ПО



Проблема



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



В идеальном мире, конечно, можно рассчитывать на детально скопированную пользовательскую инфраструктуру. Но наш мир реален, и в нем, в том числе, существует ряд причин «против» развертывания такой копии: трудно управлять изменениями, поскольку команды, у которых есть полноправный доступ к ОС, вносят изменения буквально «на лету». Развертывание такой инфраструктуры отнимает время и силы, а ресурсы на поддержку лимитированы. Ну и зачастую у компании просто нет аппаратных ресурсов для развертывания.



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



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



А что если для решения подобных проблем задействовать публичные облачные ресурсы?



Вариант решения



Естественно, для всех машин, входящих в производственную инфраструктуру, которой я пользуюсь, регулярно создаются точки восстановления. И вот я попробовал восстановить один из сервисов из резервной копии напрямую в облачную инфраструктуру Microsoft Azure’s Infrastructure as a Service (IaaS)



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



Для этого мне понадобилось вот что (см. рис.3):




  • Резервная копия (VBK), созданная с помощью Veeam Backup & Replication (или Veeam Backup Free Edition или Veeam Endpoint Backup)

  • Подписка Microsoft Azure

  • Veeam Direct Restore to Microsoft Azure

  • Veeam FastSCP for Microsoft Azure (я использовал его для загрузки данных в\из ВМ Azure)



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



2. Тестирование патчей и обновлений



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




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

  • вариант с «волновым обновлением», т.е. сначала патч ставится на 10% серверов, и за их состоянием ведется наблюдение в течение недели. Затем патчатся другие 10%, и еще через неделю – все оставшиеся. Плюс такого подхода в том, что в случае критической ошибки она затронет не всю инфраструктуру, но минус в том, что инфраструктура все же находится под угрозой, и этот риск не всегда оправдан.



Вариант решения



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



Собственно процедура, которую я выполнил для создания тестовой среды, аналогична описанной в предыдущем разделе – разве что может понадобиться восстановить в Microsoft Azure меньше ВМ (в зависимости от ряда настроек). Например, если у вас 3 идентичных веб-сервера, то вы можете протестировать один из них. То же относится и к БД, и к «среднему звену» (см. рис.4).



3. Тестирование резервных копий и планов послеаварийного восстановления



Зададимся простым вопросом: как часто мы тестируем бэкапы? А план послеаварийного восстановления? Раз в неделю, в месяц, в год, или вообще ни разу?



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



И снова на помощь может прийти публичное облако. Восстановление из резервной копии в облачную инфраструктуру имеет ряд преимуществ, например:


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

  • Как только тестирование закончено, можно очень быстро избавиться от неиспользуемых более ресурсов

  • Дополнительное оборудование (брандмауэры, роутеры и пр.) настраивается в том же облаке

  • План послеаварийного восстановления тщательно проверен и задокументирован

  • Отличный шанс проверить и задокументировать возможность восстановления инфраструктуры в публичное облако на случай, если вся инфраструктура пострадает в результате аварии





Вариант решения



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



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



Заключение



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



Об авторе



Александр Ширманов, R&D Director, Veeam







Azure Marketplace



Более 3300 разнообразных решений вы всего сможете найти на странице Azure Marketplace. Вы можете найти больше информации о магазине решений Azure Marketplace на нашем русскоязычном портале.



Пользователи Azure могут получить быстрой доступ к решениям Veaam через удобный Azure Marketplace. Начните работать с Veeam уже сегодня!



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282568/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Немного о «законе Мура»

Понедельник, 25 Апреля 2016 г. 12:54 (ссылка)





Согласно «закону Мура», количество транзисторов, размещаемых на кристалле интегральной схемы, должно удваиваться каждые 24 месяца, а их стоимость – оставаться на одном уровне. Но практически сразу после выдвижения этой гипотезы начались разговоры о «смерти» этого закона – ведь в реальном мире ничто не может расти бесконечно (даже если рост – экспоненциальный).



Как заявлял сам Мур, его «закон» предполагал не только снижение размеров транзисторов, но и падение их стоимости. Как отмечает издание Economist, еще несколько лет назад появилась тенденция, которая может привести к «концу закона Мура». Когда появились транзисторы 28-нм, производители отметили тот факт, что затраты на их создание увеличиваются. На постройку заводов, изготавливающих полупроводники по новым технологиям, необходимо больше $6 млрд. Другими словами: дальнейшее снижение размеров транзисторов возможно, но их стоимость будет расти.



Во времена появления закона Мура проектирование микропроцессоров действительно происходило в соответствии с этим законом. Но с уменьшением размеров транзисторов технологии для их изготовления становятся всё сложнее и изощрённее. Так, в начале 2000-х тоже казалось, что этой прогрессии приходит конец, но различные технические средства, разрабатываемые в то время, поддерживали «жизнь» закона Мура. Был представлен «растянутый» кремний, обеспечивающий производство 90-нм транзисторов.



Для 45-нм транзисторов были изобретены новые материалы, увеличивающие ёмкость (затвора) каждого транзистора. А трёхмерные транзисторы (tri-gate transistors), изготовленные по технологии 22 нм, только поддержали закон Мура.



Но и эти технологии не могут развиваться вечно. Фотолитография, используемая для производства чипов, работает на пределе своих возможностей: свет с длиной волны в 193 нм используют для создания чипов с элементами размером всего 14 нм. Слишком большую длину волны света можно уменьшить, но это ведёт к ещё более сложному и дорогостоящему производству. Так, возлагались надежды на «экстремальный» ультрафиолет с длиной волны всего в 13,5 нм, но оказалось, что его довольно сложно использовать в производстве.



Даже при использовании ультрафиолета неизвестно, насколько можно уменьшать транзисторы. Ведь при размере в 2 нм их ширина составит всего 10 атомов, и тогда они вряд ли будут надёжно работать. Кроме того, в этом случае перед инженерами встанут проблемы энергопотребления и охлаждения: чем плотнее расставлены транзисторы, тем сложнее доставить к ним энергию и отвести её от них.







Не стоит забывать и про фактор стоимости – конец закону Мура может положить не физика, а экономика.


Большие компании вроде Intel и AMD будут инвестировать миллиарды долларов до тех пор, пока они уверены, что прибыль покроет изначальные вложения. Однако каждый раз, когда транзисторы становятся меньше, их производство становится всё дороже.



Таким образом, в ближайшем будущем может наступить момент, когда «гиганты» не будут финансировать разработку более маленьких транзисторов, так как она попросту не будет рентабельной. И если кто-то вроде Intel перестанет гнаться за уменьшением транзисторов, его примеру последуют и остальные производители, что приведёт к «смерти» закона Мура.



Экономический фактор уже влияет на производство микропроцессоров. Так, Intel планировала переключиться на 10-нм транзисторы в 2016 году с процессорами Cannonlake – уменьшенной версией продаваемого сейчас 14-нм Skylake. Но в июле 2015 она поменяла свои планы. Новое поколение процессоров – Kaby Lake – будет выпущено в третьем квартале 2016 года с использованием 14-нм технологии. Планы на Cannonlake и 10-нм остаются, но выпуск этих процессоров ожидается не раньше второй половины 2017 года.



Все это осложняется тем, что новые транзисторы все сложнее использовать. В 1980-х и 1990-х преимущества от дополнительных транзисторов были очевидны – каждое последующее поколение процессоров было быстрее, и компьютеры того времени получали значительный прирост мощности только за счёт улучшения процессоров. Но такое простое увеличение производительности пошло на убыль в начале 2000-х. Частота процессоров сильно ограничивалась из-за нагрева, а мощность одного процессорного ядра росла относительно медленно. Вместо этого, производители стали делать процессоры с несколькими ядрами: теоретически, это увеличивает мощность процессора.



Все эти сложности говорят о том, что производственные планы компаний скоро перестанут опираться на закон Мура. Издательство Nature пишет, что новый план ITRS также будет использовать другой подход. Сейчас производители чипов нацелены на быстро растущий рынок мобильных устройств. Для них нужны чипы не только с логическим модулем (транзисторами) и кэш-памятью, а также с модулями оперативной памяти, регуляции энергопотребления, аналоговыми компонентами для GPS, сотовой связи, Wi-Fi и так далее. Все эти модули сейчас создаются в разных технологических процессах, и для производителей чипов более актуальна интеграция старых и разработка новых технологий построения таких составных микропроцессоров, чем очередное удвоение количества логических транзисторов.



И всё-таки новые технологии ещё могут дать шанс закону Мура. Текущая технология производства микросхем (КМОП), использующая кремний, может быть заменена чем-то другим, в том числе и в 7-нм транзисторах Intel. Более перспективные (по сравнению с кремнием) материалы: антимонид индия (InSb) и арсенид галлия-индия (InGaAs), а также (возможно) углерод, как в форме нанотрубок, так и в форме графена.



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



Но сейчас, когда мы не можем точно сказать о грядущих прорывных инновациях, срок действия закона Мура (в его «последней редакции») подходит к концу. И в этом нет ничего катастрофического: производителям микросхем открываются новые рынки вроде мобильных устройств и машин для дата-центров. Поэтому, даже если закон Мура и «умрёт», это не сильно скажется как на жизни обывателя, так и на жизни производителя.



Материалы по теме из нашего блога на Хабре:





P.S. Дополнительные материалы о разработке провайдера виртуальной инфраструктуры 1cloud:







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282377/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как можно зарабатывать на Wi-Fi в общественных местах (если вы не платите, то вы — товар)

Четверг, 21 Апреля 2016 г. 10:24 (ссылка)



Карта расположения Wi-Fi устройств в реальном времени показывает точки наибольшего интереса посетителей выставки



С развитием iBeacon’ов, хорошего широкополосного 5-гигагерцевого канала, появлением довольно доступных антенн с beamforming сегодня есть возможность давать быстрый коннект под HD-видеопоток даже в таких традиционно сложных местах, как стадионы. Кстати, у нас уже был проект, где мы делали для стадиона приложение с возможностью просмотра повторов сразу после гола на телефоне и справкой по тактической расстановке, статистике игроков и так далее.



Сейчас Wi-Fi получил новые фичи для следующих мест:


  • Музеев (технология заменяет гидов).

  • Спортобъектов от 5–8 тысяч зрителей.

  • Выставок (теплокарты как на картинке выше, навигация).

  • Торговых центров (навигация и реклама).

  • Транспортных узлов (сервис в аэропортах вроде авторегистрации на рейс).

  • Складов (поиск товара).

  • Туристических объектов (открытый Wi-Fi и аналитика).



Ниже — подробнее о том, как, почему и зачем. И где вы покупатель, где вы товар.



Музеи



Небольшие iBeacon могут крепиться там же, где крепятся информационные таблички. Пользователи забирают приложение музея (или получают девайс с ним) и открывают Wi-Fi-канал для загрузки контента. По Bluetooth маяки передают свои маркировки в определённых секторах (например, в 10 метрах от картины «Мона Лиза» или в 2 метрах перед стендом «Катана есаула Шишикова»). Приложение в ответ на это понимает, где находится пользователь, показывает ему контент на его языке или проигрывает нужный блок из аудиогида.



Монетизируется оно двумя путями: дополнительным контентом (вроде «39 рублей за полную экскурсию» и «Закажите копию этой картины, она будет готова к концу экскурсии»), а также тем, что музей получает людей, фактически подписанных на его PUSH-уведомления. То есть новую аудиторию, которую можно уведомить о мероприятии, новой выставке или о чём-то ещё подобном. Дополнительный плюс — контент может быть виден и вне музея, например, где-то ещё в городе при посещении достопримечательностей.



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



Сейчас в мире в качестве терминалов часто используются iPod второго поколения с экраном.



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



Что касается монтажа, то важно знать вот что:


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

  • Используется низкоэнергетический Bluetooth (одной батареи, по заявлениям производителей, хватает на 5 лет). В моей практике, конечно, не так — полтора года.

  • Есть решения для применения на открытом воздухе и в агрессивной среде.



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



Спортобъекты



Различные хоккейные арены, ледовые арены, волейбольные и баскетбольные спорткомплексы, футбольные стадионы, всё то, что от 5–8 тысяч зрителей… — можно ставить Wi-Fi высокой плотности и делать интерактивную навигацию.



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



У нас сейчас большую часть арен достраивают к чемпионату мира. Обидно, что по поводу режима наследия не особо думают, а ведь по факту там будут играть команды, которые представлены в регионах с объектами. На те же «Крылья Советов» приходит много зрителей: у них есть фаны, люди, которые ходят семьёй. Операционные затраты на поддержание будут очень большими, и потребуется большая бюджетная статья. Сейчас уже можно начать покрывать операционку, используя их инфраструктуру, которую им и так делают. Контент, мобильное приложение и лёгкая модернизация вайфая — и у вас баннеры спонсора в приложении, неагрессивная допинформация, товары фанатских магазинов, брендированные лучшие моменты матча. Чистый доход.



На Западе к этому прикручивают ещё навигацию — как из места 21F третьего сектора пройти в любимый KFC в ресторанном дворике, например.



У NBA и у НХЛ больше всего таких модулей, вот, например НХЛ «Питтсбург Пингвинз» на стадионе CONSOL Energy Center:





Это схема стадиона. На нём 781 HD-монитор и сеть высокой плотности, развёрнутая на базе решений Cisco. На разные зоны транслируется разный контент для телефонов. В два раза выросло количество рекламодателей, в три — количество поступлений от спонсоров. Примерно 80% зрителей сохранили контент, который они смотрели, ретранслировав его в социальные сети.



А футбольный клуб «Реал Мадрид» сделали ещё интереснее. Помимо всего прочего, в приложении есть модуль фотографии с игроком. Фотографируешь селфи под рамку, туда вставляется игрок, вроде как он вас обнимает на поле — и получается отличное фото. Стоит это из приложения чуть меньше пары евро. Не знаю, кто и зачем это делает, но спросом пользуется.







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



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



Выставки



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



Можно делать график загруженности внутри помещения, аналитику потоков, аналитику интересности докладов отдельных выступающих, короче — Яндекс.Пробки внутри помещения. И, конечно, навигацию, связанную с расписанием.



Торговые центры



Главная проблема торговых площадок в кризис сейчас — малая наполняемость. Людей нет. Wi-Fi не помогает привлечь новых людей, но помогает точнее находить нужное в торговом центре за счёт не очень агрессивных PUSH-акций и рекламы, функциональности инфостоек.



С помощью Wi-Fi можно определять наиболее людные места в торговом центре, учитывать длину сессии по магазинам и так далее — в общем, как Google Analytics, только в реальном мире. Аутентификация через социальные сети позволяет получать маркетологам данные о людях в торговой зоне (при условии, конечно, что страничка пользователя в соцсетях заполнена корректно). На основании полученной информации мобильное приложение таргетирует (возраст, пол и пр.) товары и услуги для посетителей.



Транспорт



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



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



Есть бизнес-кейс одного регионального аэропорта, где была развёрнута Wi-Fi-инфраструктура Cisco и внедрена система навигации внутри помещения и трекинга компании DECK.



Вот такие ключевые задачи были у аэропорта:


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

  • Предоставление пассажирам информации и допуслуг в мобильном «Онлайн-табло» и услуги.

  • Оптимизация работы персонала при обслуживании воздушного судна и прохождении ТГО.



В проекте развёрнутая Wi-Fi-инфраструктура позволила запустить мобильное приложение для пассажиров, где есть удобный интерфейс и навигация с модулем просмотра, а также специальное мобильное приложение для персонала, обслуживающего воздушное судно при ТГО. Появилась возможность продавать спонсорские пакеты и рекламу через мобильное приложение.



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



Естественно, в этих же приложениях показывается онлайн-табло рейсов.



Некоторые аэропорты не дают на клиентов навигацию, но используют приложения для оптимизации работы персонала при обслуживании воздушного судна и прохождении ТГО, задавая их движение маяками.



Склады



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



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



Туристические объекты



Тут просто. Wi-Fi бесплатный, но чтобы войти, пожалуйста, расшарьте ссылку в Facebook. Более гуманный вариант — просто дать Wi-Fi и показать, что вот с этого места получается отличный инстаграммный пост. Люди делятся картинками и продвигают место. Более сложный вариант — всё тот же музейный гид.



Регистрация в подобных местах идёт по телефону или профилю соцсети (где есть телефон) в соответствии с Постановлением Правительства РФ от 31 июля 2014 г. №758 «О внесении изменений в некоторые акты Правительства Российской Федерации в связи с принятием Федерального закона “О внесении изменений в Федеральный закон “Об информации, информационных технологиях и о защите информации” и отдельные законодательные акты Российской Федерации по вопросам упорядочения обмена информацией с использованием информационно-телекоммуникационных сетей”». Это значит, что можно при желании отслеживать пути отдельных пользователей и использовать их в аналитике.







Архитектура такая: есть PON (точка навигации, якорь), объект POI (любая значимая точка на карте, по которой показывается что-то дополнительное), событие (условие для срабатывания триггера, чаще всего — PON и радиус) и действие (сценарий для события).



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




  • В рамках интеграции мы используем решения Cisco (инфраструктура Wi-Fi), DECK — система навигации внутри помещения и трекинга. Если интересно подробнее — пишите в личку.

  • Что касается маячков, то здесь «поле для маневров» довольно широкое. Сотрудничаем с широким спектром производителей: от Польши до Китая. Принцип работы маяков один и тот же, поэтому не могу выделить какого-то производителя отдельно.

  • Моя почта — AChuvilin@croc.ru





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282101/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

20 апреля весь день, впервые онлайн — IT Director Briefing 2016

Вторник, 19 Апреля 2016 г. 15:30 (ссылка)





Ключевое событие года Microsoft в Северо-Западном регионе расширяет границы!

Наше ежегодное мероприятие IT Director Briefing выходит в онлайн, благодаря технологии Skype Broadcasting!



Приглашаем вас присоединиться с помощью онлайн трансляции к общению с ведущими ИТ руководителями компаний крупного и среднего бизнеса Санкт-Петербурга, которое состоится 20 апреля!



C 2011 года, IT Director Briefing неуклонно расширяет аудиторию участников благодаря вниманию и интересу к ИТ технологиям со стороны бизнеса. В этом году, мы предлагаем вам присоединиться к сообществу ИТ Директоров, использующих технологии Microsoft для расширения возможностей бизнеса и ИТ инфраструктуры!



Требуется регистрация!







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281963/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<инфраструктура - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda