Угадайте, что здесь произошло

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

Вторая вещь, способная расшатать психику даже самых стойких инженеров пришла с удалёнкой, то есть с пандемией. Это помощь по VPN. Мы подключаемся к рабочему месту сотрудников и просим ничего не трогать. Но нет. Они очень хотят помочь. А помощники они от бога. Вот я пытаюсь что-то нажать, а мышку вдруг начинает водить кругами. Это пользователю стало скучно, и он ей покрутил. Может кнопку любую нажать. Обычно любая — это покрупнее. Ещё круче, когда пользователь не просто пьёт чай, а помогает активно. «А я знаю, что вот надо сюда», – и начинается борьба за мышь: кто кого победит, кто быстрее мышкой пользуется и точнее кликает. Но пользователи обычно проигрывают, у них аим и префайр на кнопки плохие, и ещё они часто горячих клавиш не знают.

Я занимаюсь внедрением инструментов по ESG (это экология и устойчивое развитие) в России в крупных корпорациях.

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

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

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

Давайте разбираться, как это выглядит. А то будет как с заменой бумаги на планшеты: «сэкономили 2 тонны древесины» звучит хорошо, а «закупили ещё 500 Li-ion батарей в алюминиевых корпусах» уже хуже.

Квантовый процессор Google на базе массива из 54 кубитов.

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

За последние годы уже несколько раз компании объявили, что достигли квантового превосходства – способности решать задачи, невыполнимые для классических компьютеров. В 2019 году Google опубликовала статью в Nature, заявив о достижении квантового превосходства на массиве из 54 кубитов. 3 декабря 2020 года уже китайские учёные сообщили о достижении квантового превосходства с новым суперкомпьютером Jiuzhang на запутанных фотонах. В этом исследовании за 200 секунд была решена задача, которая на обычных суперкомпьютерах решалась бы более 1,5 миллиардов лет.

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

• Уровень ошибок – квантовые компьютеры отдают правильный результат вычислений с какой-то долей вероятности.
• Время удержания когерентности – вам не нужен квантовый компьютер на 300 кубитов, который потеряет свою квантовую когерентность раньше, чем вы начнёте вычисления.

Предлагаю пройтись по текущим достижениям в этой области. Посмотрим, почему РЖД стал крупнейшим квантовым оператором в России. А ещё попробуем понять, пора ли уже внедрять шифрование McEliece в TLS и паниковать или можно ещё немного подождать.

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

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

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

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

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

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

Итак, давайте покажу процесс верхнеуровнево: как разобрать и собрать процессы заново, выстраивая это всё в систему.

Привет, Хабр! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.

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

По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.

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

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

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

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

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

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

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

Откуда появилось Sec? Безопасность банка выставила высокие требования к тому, как внешний подрядчик может работать в сетевом сегменте, какой у кого доступ, как и кто работает с кодом. Просто ИБ ещё не знала, что когда подрядчики работают снаружи, мало какие банковские стандарты соблюдаются. А тут за пару дней надо их начать соблюдать всем.

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

В этот момент и началась история DevSecOps, про которую я хочу рассказать.

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

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

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

Рассмотрим ситуации, когда выгоднее фиксированные тарифы, а когда — pay-as-you-go-концепция (PAYG). Плюс рассмотрим, что можно выключить лишнего, и где чаще всего впустую расходуются ресурсы. Пройдёмся по основным видам ресурсов: CPU, RAM, виртуальным дискам, сети и бэкапам.

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

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

Собственно, именно в момент обрыва мы и перешли на удалёнку. В своём собственном офисе. Точнее, в двух сразу.

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

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

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

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

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

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

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

Но мы пошли чуть дальше: в городе Новомосковске (120 тысяч жителей) поставили на светофоры камеры, поменяли все контроллеры и связали всё это в одну сеть. Бюджет у города небольшой, поэтому правила пока эвристические без всякого космоса вроде data mining и машинного обучения, светофорных объектов не очень много (потому что даже поставить 21 камеру уже дорого), но мы смогли добиться вполне конкретных результатов.

Скорость прохождения перекрёстков с нашими «умными светофорами» и обычных перекрёстков рядом увеличилась. Мы научились приоритизировать поток машин утром на крупный завод, считать и обрабатывать транзитные фуры и даже замахнулись на ГЛОНАСС-датчики «скорой», чтобы убирать возможные заторы перед ними.

Оцените связки в средней части схемы. Ниже к ним вернёмся

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

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

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

Итак, что такое сетевая фабрика с наложенными сетями и SDN?

Часто, когда я говорю кому-то про уязвимость, на меня смотрят как на сумасшедшего с табличкой «Покайтесь, ибо конец света близок»!

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

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

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

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

Тестирование и QA тоже хорошо отлажены чаще всего.

А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA.

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

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

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



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

В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.

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

Так вот, не будет.

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

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

То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.

Аgorafreight.com — первый в России сервис для онлайн-расчета стоимости и заказа авиа-, авто- и контейнерных перевозок, сборных грузов всеми видами транспорта, включая ставки «от двери до двери».

Об истории проекта Agorafreight рассказывает руководитель проектов Reksoft (входит в ГК «Техносерв») Дмитрий Долгих.

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

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

Следствие — несколько разные векторы у CFO и CIO. Выражается это в том, что ИТ-директор часто хочет принести всё «домой» и поставить стойку в офисе, а финансист не видит в этом решительно никакого смысла. И так уж получилось, что CIO косвенно подчиняется именно CFO, поэтому всё заканчивается переездом в облако.

Как написал kaichou в комментарии: «а потом, пару лет спустя, выясняется, что на облако в год тратится столько денег, сколько стоил весь собственный серверный парк». И эта ситуация вполне нормальна для финдиректора. Сейчас постараюсь объяснить, как он в такой ситуации мыслит.

У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами). Они имеют несколько точек сохранения снэпшотов.

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

У методов есть плюсы и минусы, сейчас про них расскажу.