Как-то к нам пришел один прогрессивный заказчик из города N, что в средней полосе России, и сказал: «Хотим чтобы дата-центр на 100% фрикулинге работал круглый год. Можете посчитать, это реально вообще? И если да, какая технология вам видится наиболее логичной?». Мы с холодильщиком воодушевились, ибо не каждый день тебе предлагают поработать над таким нетривиальным для средней полосы России проектом, и начали считать. Под катом много цифр и теории по части охлаждения дата-центров.

Знаете, почему проекты в крупных компаниях делаются по полгода? Потому что один из самых медленных процессов — это общение с заказчиком для выявления деталей его потребностей. Простое уточнение ТЗ (на гвозди или на клей надо крепить) может занимать до трёх месяцев. Я сейчас, конечно, несколько утрирую, но реальность в том, что почти никогда нельзя просто взять написать или позвонить и получить прямой ответ. Надо дождаться всех из отпусков и собрать совещание.

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

Это понимали мы и понимало руководство СИБУРа, нашего мощного промышленного партнёра, который помогал с проведением и организацией хакатона. Надо было устранять зазор между тем, что уже сделано и тем, что можно и нужно сделать по автоматизации. Для этого мы решили собрать на одной площадке сразу четыре стороны:

1. Крупнейшие промышленные компании страны.
2. Вендоров технологий с меняющихся рынков.
3. Молодых разработчиков.
4. ИТ-инженеров с опытом работ в сфере или в конкретных нужных технологиях.

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

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

Свиноматка кормит поросят до 26-го дня. За это время она может на них прилечь, что приведёт к тому, что поросят станет чуть меньше, чем было в самом начале. Чтобы этого избежать, используются вот такие станки, как на фото, которые исключают её повороты и хождение по загону. У одной свиноматки — от 10 до 15 поросят. На первой неделе поросята ещё не понимают, что эта туша опасна, и могут не уйти из опасной области, когда она ложится. Когда это происходит, поросёнок громко визжит примерно в половине случаев. Часть поросят можно спасти, если вовремя поднять свинью. Задача — детектировать такие случаи и вызывать сотрудника.


Как видите, этот вариант решения распознаёт поросят на видео и считает их.

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

Когда представитель MARS сказал, что принесёт обучающую выборку, мы не думали, что это будет четыре коробки шоколадок Twix Minis.

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

Чушь. Познакомьтесь с поколением Z. Они скоро станут вашими коллегами, подчинёнными и даже начальниками. Они обычные люди, просто получившие смартфон раньше, чем научились читать. Умные, целеустремлённые, образованные. Да, они не жгли тряпки на заброшенной стройке и не ели муравьёв в песочнице, но зато многие из них уже успели собрать свой первый школьный проект на Arduino и вовсю осваивают 3D-печать.

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

Карта полёта, отмечены точки с концентрацией метана свыше 3 000 ppm*m. И это много!

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

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

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

Услуга автоматизированного замера уровня метана с помощью дронов очень востребована в Европе.

Мы, с нашими партнёрами из компании Пергам, провели совместную работу в этом направлении и получили интересный результат.

Привет!

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

С другой стороны, частые переговоры означают много поездок. Иногда везёт. Вот в Дубае выходные пятница и суббота, а воскресенье — рабочий. При этом рейсы на воскресенье дорогие, и куда выгоднее лететь в пятницу. Встреча по поводу наших разработок по машинному зрению для дронов была на воскресенье, и когда наш переговорщик прилетел, заказчик извинился и сказал, что не получается, и нужно перенести ещё на пару дней. Так у него получились незапланированные выходные. Ну а дальше он закономерно вышел на пляж и уснул. После чего всем говорил, что сгорел на работе. Но интересно не это: дело в том, что ещё один наш коллега как раз застрял посреди тундры. Это примерно два часа вертолётом от Нового Уренгоя, и, кроме вертолёта, там транспорта нет. У него была метель — и, как следствие, нелётная погода. Он прибыл, обследовал талевые канаты и не смог вылететь. К началу истории уже сидел там два дня. Синоптики обещали открыть площадку только ещё через три дня. Из развлечений у него там была еда в столовой на месторождении, настольный теннис с вахтовиками и SMS на телефоне. Вот они друг другу и жаловались, кто и где застрял.

— Да этот ЦОД можно развернуть и настроить, пока ты пиццу заказываешь!

Я бросил эти слова на совещании, и расплата пришла немедленно. Коллега предложила заказать пиццу. Оплачивает проигравший: если я успеваю собрать ЦОД — то она, если не успеваю — то я.

Чёрт!

В общем, встречайте стресс-тест: гиперконвергентное решение от Cisco с простой настройкой против приготовления пиццы.

Одна из главных задач ИТ сейчас в производственном секторе — уменьшить количество аварий.

Что сейчас меняется на производствах?

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

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

Иногда бывает так:

— Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.

И мы едем. Ночью. На другой край страны.


Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа

Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.

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

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

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

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

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

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

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

Следующая история гораздо веселее. Мы как-то получили железку за пару миллионов рублей в коробке с датчиками наклона, вибрации и влажности. Всё целое. Аккуратно сняли упаковку, а железяка гнутая. Мистика.

Корпус прямо дугой. Красиво так.

Заказчик захотел VDI. Очень присматривался к связке SimpliVity + VDI Citrix Virtual Desktop. Для всех операторов, сотрудников офисов по городам и так далее. Там пять тысяч пользователей только в первой волне миграции, и поэтому они настояли на нагрузочном тестировании. VDI может начать тормозить, может спокойно прилечь — и не всегда это случается из-за проблем с каналом. Мы купили очень мощный пакет тестирования специально для VDI и грузили инфраструктуру, пока она не легла по дискам и по процессору.

Итак, нам понадобятся пластиковая бутылка, софт LoginVSI для навороченных тестов VDI. У нас он с лицензиями на 300 юзеров. Потом взяли железо HPE SimpliVity 380 в набивке, подходящей для задачи максимальной плотности пользователей на один сервер, нарезали виртуальных машин с хорошей переподпиской, поставили на них офисный софт на Win10 и начали тестить.

Поехали!

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

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

Если очень коротко — мы умеем быстро мигрировать из AWS. У нас совместимый API. Мигрировать клиентов из Google тоже можем. И в ближайшие недели мы готовы делать миграцию бесплатно и давать месяц на тесты в нашем облаке без договора и без гарантийного письма, просто по карточке компании. Не понравится — ничего платить не надо.

Ниже — howto для разных типов выгрузки ВМ с Амазона.

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

Тогда «облачных» вычислений в России не было, как и облачных хостингов. Собственно, и само слово-то почти не использовалось на рынке. Но мы уже видели по Америке, что там подобные инсталляции пользуются спросом. У нас были за плечами большие проекты создания HPC-кластеров для авиаконструкторов на 500 узлов, и мы верили, что облако — это такой же большой вычислительный кластер.

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

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

Пример монтажа на стадионе ЦСКА

Итальянские и английские футбольные фанаты считались самыми агрессивными. Но теперь они дома не бузят. Почему? Потому что их лишают пожизненно права посещения стадионов. Поэтому они бузят на евро, на ЧМ, во Франции. У нас тоже начинается такое: особо эмоциональные фанаты легко могут словить запрет на посещение арены на достаточно продолжительный срок.

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

Вообще, есть два мифа про безопасность на стадионах:

1. Что видеонаблюдение не помогает в предотвращении преступлений.
2. И что биодетекторы — это прошлый век.

Тебе хана, если ты не влез в бизнес-процесс заказчика, а копаешься только в ИТ-процессе.

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

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

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

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

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

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

«Денис, ты теперь инженер по развёртыванию». Офигеть, дайте две. В общем, я работаю в КРОК, который славится огромными проектами. В этом проекте мы поддерживали внедрение гигантской аналитической системы класса data lake для нескольких тысяч пользователей объёмом 150 ТБ. Пилят её несколько команд разработки, в общей сложности примерно 40 человек.

На них приходится четверо инженеров по инфраструктуре (опсов, админов, то есть нас) — мы чаще всего были нужны для того, чтобы устанавливать софт на стенды, перезагружать машины (первая надежда разработчика: не работает — попроси инженера перезагрузить), накатывать схемы БД и так далее.



Разработчики пишут код, который сливается в репозиторий. Из него Jenkins рождает сборки, которые выкладывает на шару. Развёртывание системы с нуля первый раз у меня заняло 4 часа 15 минут по таймеру. Для каждого из порядка десяти компонентов (скрипты разных БД, Tomcat-овские приложения и т. д.) в нужном порядке надо было взять файл с шары, разобраться, где и в скольких экземплярах его нужно развернуть, поправить настройки, указать, где ему искать другие компоненты системы, связать всех со всеми и ничего не перепутать.

Пальцы закровоточили — начал скриптовать. Началось с одного маленького скрипта.

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


Новое поколение, «бронепоезд» на жаргоне. Справа наша давняя мечта — решётка, чтобы крыс не засасывало.

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

Старые советские ДДИБП, которые стояли на Байконуре, принципиально не отличаются от своих современных аналогов. Те же волчки, те же дизели. Но есть масса полезных нюансов. Вот о них и о том, как вообще эволюционирует такое «кондовое» железо, и поговорим.

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

Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 30–35 Тб (но подешевле раз в пять, помедленнее, попроще, без резервирования) и отреплицировать базу на неё. А затем работать с копией. Хороший план?

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



Расскажу, как на одном узле с физической базой мы развернули 7 тестовых площадок, изолированных друг от друга.