Рубрика «Блог компании ТЕХНОСЕРВ»

image

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

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

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

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

image

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

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

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

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

Боремся с пробками в маленьком городе за небольшой бюджет: результаты 6 месяцев проекта - 1

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

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

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

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

Опыт реализации сетевых фабрик на базе EVPN VXLAN и Cisco ACI и небольшое сравнение - 1
Оцените связки в средней части схемы. Ниже к ним вернёмся

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

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

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

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

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

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

Портал тестовых сред, или Спасём наш девопс - 1

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

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

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

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

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

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

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

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

Платформа автоматизированного реагирования на инциденты ИБ - 1

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

Обезл***вание д***ных — это не просто рандомизация - 1

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

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

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

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

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

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

Почему финансовые директора так хотят перевести капитальные расходы на ИТ в операционные - 1

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

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

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

Реакция на аварию: растянутый кластер против DR-площадки - 1

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

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js