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

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

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

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

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

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

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

Мы используем для своего облака дата-центр DataPro. Да, интегратор «Техносерв» строил дата-центры и серверные узлы, да, мы умеем это делать, да, у нас есть нужные инженеры в штате, но мы предпочитаем отдавать именно размещение на аутсорс. Почему? Потому что дата-центр в виде IaaS — это, очень упрощая, как холодильник или склад. Ничего романтического — просто место, куда надо поставить сервер. Охлаждение, питание, регламенты и всё остальное — это очень много компетенций, которые не нужны в облаке. Хранение чужих серверов включёнными — это отдельный бизнес.

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

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

100G с разбивкой на 4х25 в нашем дата-центре

Основа работы сетевого архитектора на *aaS-проектах — это как строить здание, которое эволюционирует. Вроде была пятиэтажка, когда построили четыре этажа, стало надо делать ещё 21, потом понадобилось пристроить домики, соединённые туннелями под землёй, а потом всё это должно стать огромным жилым комплексом с крытым двориком. И ещё там внутри жильцы, и им нельзя перекрывать канализацию, водопровод и подъезды.

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

Меня зовут Людмила, я 7 лет работаю продакт-менеджером. Сейчас расскажу, на что это похоже.

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

Продакт-менеджер сильно пересекается по функционалу со многими другими ролями. Может выполнять задачи руководителя проекта. И ещё делать кое-что до и после этого. Вот его функционал вкратце:

1. Анализирует, что может понадобиться пользователям и исследует рынок. То есть придумывает идеи новых проектов и ставит им приоритеты.
2. Совместно с техкомандой выбирает техническое решение.
3. Просчитывает экономику продукта и определяет, стоит ли этим, вообще, заниматься.
4. Собирает рабочую группу, ставит задачи архитекторам и остальным ключевым лицам проекта.
5. Следит за всем-всем-всем по организации, в частности, отвечает за взаимодействие с партнёрами и вендорами.
6. После внедрения сопровождает продукт, занимается его развитием и усовершенствованием минимум год.
7. Время от времени просыпается ночью с горящими глазами и идеей нового продукта.

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

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

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

Вот, например, база данных размещается на 7K-дисках и на слабой виртуальной машине. Почему так? Потому что нужную производительность оценили в среднем. А в реальном бизнесе среднего не бывает: обычно это цепочка мелких пиков между практическим отсутствием нагрузки. У магазинов ночью мало что происходит, у НИИ — между длинными расчётами.

Расскажу чуть больше про типичные ситуации.

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

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

Мой любимый эпизод — это просчёт цен на новое оборудование в офисе (стойка из серверов дешёвого сегмента или переделанных ПК) и облака:

— Так. Лицензия на гипервизор. Зачем за неё платить? Мы никогда лицензию не покупали… Россия же, хе-хе! Поддержка на железо в стойке? К чёрту, без поддержки обойдёмся, у нас админ шарит. Что там ещё, бекап? У нас уже есть палёный...

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

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

Более 10 лет в разных должностях я занимаюсь проектным управлением. Поработал в четырёх крупных интеграторах и сейчас возглавляю департамент из 100 человек. За время работы какими только проектами не приходилось управлять: внедряли SAP, автоматизировали деятельность предприятий, разрабатывали ИСы для госзаказчиков, проектировали и строили уникальные ЦОДы, делали военные ОКРы, проводили сложные миграции ИС… — даже строили под ключ электростанции в Белоруссии и угольные котельные в п. Черском (2000 км от Якутска). Основной сложностью тогда оказалась доставка оборудования и материалов — река была проходима только 5 месяцев в году. Вылез за дедлайн или просто поймал холодный год — потерял 7 месяцев. Либо дорогущий вертолёт. Все проекты разные, и каждый по-своему уникален.

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

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

Представьте, что вы нашли трёх друзей, которые родились с вами в один и тот же день. У вас одинаковая дата рождения, одинаковый пол, и вы можете определёнными усилиями сменить имена в рамках закона. В итоге получится четверо одинаковых людей. Будет ли набор «Ф. И. О. + дата рождения + пол» персональными данными?

Ответ, как это ни странно, — да.

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

Ранее в законодательном определении содержалось указание на конкретные примеры, которые каждый в отдельности или в совокупности с другой информацией составляли персональные данные. В текущей же редакции ст. 3 Федерального закона № 152-ФЗ примеров персональных данных не приводится, т. к. законодатель сделал упор на «духе закона», прямо оговорив, что к таким данным относится «любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу», отдав решение этого вопроса на откуп судебной практике.

Поэтому давайте разбирать на примерах, что есть ПДн, а что — нет.

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

— А у вас АКСУ в продаже есть?
— Нету.
— А КПВТ?
— Нету.
— А гранаты?
— Ээх, вот чего нет, того нет.

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

Мы очень беспокоились за СУБД, потому что именно на них ожидался пик syscall’ов, и потребление ресурсов облака могло вырасти больше чем на 10%.

Забегая чуть вперёд — с патчами MS SQL в некоторых тестах работает почему-то быстрее.

Роли в проекте выглядят так:

1. Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
2. Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
3. Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
4. Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.

Потом в обратном порядке проект принимается.

Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.

Дальше — имхо про то, что нужно от первых трёх ролей.

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

А ещё я видел, как аттестацию на соответствие ФЗ-152 делают по ошибке. Ниже поясню, почему она не всегда нужна.

Сейчас далеко не все понимают, что необходимо делать при развёртывании инфраструктуры не у себя в виде стойки. Российский рынок не сильно подкован в вопросах переезда в облако. Крупные госзаказчики интуитивно понимают, что облачные технологии (в частности гособлако) им необходимы, но не понимают, что нужно для этого сделать. У нас всё готово для таких ситуаций, есть специальный центр компетенций по информационной безопасности. Платформа Техносерв Cloud аттестована по требованиям безопасности информации и позволяет размещать ГИС и ИСПДн, к которым предъявляются наивысшие требования по защите информации, остаётся только аттестовать решение клиента. С нашей помощью это обычно проходит за 2–3 месяца, что гораздо быстрее (самостоятельно это занимает обычно 6 месяцев).

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

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

— Рома, я задолбался быть инженером. Всё, ухожу!
Он ласково улыбнулся и сказал:
— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.

Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.

Но! Если понимаете — это будет очень увлекательное приключение.

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

Источник

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

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

Источник

Друзья, всех с прошедшим вчера Днем программиста! Жизни без багов и красивейшего кода!)

Мы продолжаем разбор облачных сервисов Техносерв Cloud и сегодня детально разложим, из чего состоит наша облачная база данных. Если заглянуть в результаты исследования, проведенного IDG Connect по заказу Oracle, увидим, что DBaaS скоро будет самым востребованным сервисом частного облака. Растет и число публичных сервисов DBaaS.

Снижение затрат за счет консолидации ресурсов, масштабирование по мере необходимости, контроль расходов, доступ к данным из любого места – всё это факторы, влияющие на выбор в пользу облачной базы данных. На рынке облачных услуг свои базы данных предлагают его ведущие игроки – Amazon Web Services, IBM, Microsoft и Oracle. Но есть одна проблема — все они разворачивают БД за пределами России, более того, далеко не все из них предлагают сервис – администрирование, управление производительностью, круглосуточную техническую поддержку (желательно на русском языке), – а только платформу.

Чтобы ответить на этот запрос рынка, мы запустили свой сервис и стали единственным российским облачный провайдером, работающим с четырьмя основными базами данных под ФЗ-152 и ФЗ-242.

Источник

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

Источник

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

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

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

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

Источник

Не так давно мы рассказали о запуске нашей новой облачной услуги – объектного хранилища Техносерв Cloud, совместимого с S3. Сегодня мы хотим перейти к конкретным техническим моментам в работе с нашей услугой, а в частности к настройкам системы резервного копирования для работы с S3-совместимым хранилищем. Сейчас практически все современные СРК имеют встроенную поддержку протокола S3 API, но не все об этом знают и, соответственно, не в полной мере используют функциональность систем.

Недавнее исследование Taneja Group определило приоритеты в использовании объектных хранилищ среди пользователей, согласно которому хранение резервных копий занимает первое место. В качестве примера для сегодняшнего поста мы взяли СРК Commvault. Подробнее об исследовании, о Commvault и настройке подключения облака к системе в нашем новом материале.