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

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

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

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

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

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

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

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

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

Самая большая голова Ленина в мире. Площадь Советов в Улан-Удэ

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

Всё было не зря.

Такие истории очень хорошо рассказывать через пару лет в курилке, но не встречать на проектах.

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



Этим наш дорогой коллега решал одну ИТ-проблему. Дело в том, что мы оснащали серверный узел в здании (маленький ЦОД на 20 стоек) серверами. Во время работ фальшпол начал гнуться — медленно так, с треском и вообще как в фильмах ужасов. Это оттого, что рядом поставили блоки ИБП, по 20 килограмм на юнит. Не проверив допуски.

Чтобы не было эффекта домино, Женя принял решение повытаскивать батарейные блоки. Это не особо помогло. Но с помощью бордюрного камня удалось чуть замедлить процесс. Ещё через час приехала команда подрядчиков, строивших этот ЦОД, с примерно 30 домкратами из автомагазина для ремонта. Три недели переделывали, только потом мы смогли продолжить.
В общении с иностранными коллегами мы описываем это как surprisingly amazing. Со своими есть более точный термин — «клоунада».

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



Шучу. Главный страх админа при переводе инфраструктуры в облако — это потеря собственной важности. Почти все боятся, что перестанут быть незаменимыми. Это иллюзия. Важно не знание технологий, а знание компании и её устройства. Технологии быстро доучиваются.

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

Потому что с момента начала виртуализации надо забыть половину того, что ты знаешь, и начать ботать сеть.

Если вы читали на ночь Олифера «Компьютерные сети» или книгу с таким же названием Таненбаума, то проблем не будет почти точно. Это когда-то было классикой админов в свитерах, а теперь стало классикой админов в галстуках.

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

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

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

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

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

Уважаемые читатели! Представляю вашему вниманию перевод методологии создания веб-приложений The Twelve-Factor App от разработчиков платформы Heroku. Мои комментарии скрыты спойлерами по ходу статьи.

Введение

В наши дни программное обеспечение обычно распространяется в виде сервисов, называемых веб-приложения (web apps) или software-as-a-service (SaaS). Приложение двенадцати факторов — это методология для создания SaaS-приложений, которые:

• Используют декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключенных к проекту;
• Имеют соглашение с операционной системой, предполагающее максимальную переносимость между средами выполнения;
• Подходят для развертывания на современных облачных платформах, устраняя необходимость в серверах и системном администрировании;
• Сводят к минимуму расхождения между средой разработки и средой выполнения, что позволяет использовать непрерывное развертывание (continuous deployment) для максимальной гибкости;
• И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки.

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

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

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

Самые известные на мировом рынке объектные хранилища — это Amazon S3 (Simple Storage Service), Google Cloud Storage и Microsoft Blobs Storage. Они надежны, доступны через интернет и масштабируются до сотен петабайт. Наиболее популярный способ доступа к объектному хранилищу — S3 RESTful API от компании Amazon. Есть и альтернатива, OpenStack Swift — поддерживает оба API и даже имеет собственное (как у Microsoft или Google, например). Дополнительно предоставляется доступ по другим файловым и блочным протоколам вроде WebDAV, NFS и FTP, но в контексте этой статьи мы тестируем только доступ по протоколу HTTPS через разнообразные API.

Для сравнения возьмем отечественные публичные объектные хранилища. Их не так много, и мы рассмотрим наиболее заметных игроков российского рынка: Mail.Ru Cloud Solutions, servers.ru, Selectel, Техносерв и Ростелеком.

Сегодня мы поговорим об очередной интересной технологии — VxLAN — что это за зверь и с чем его едят, да и вообще нужен ли он вам. Мое знакомство с данной технологией началось с изучения гипервизоров — я постоянно натыкался на термин VxLAN, но что это и как работает не знал. В один прекрасный день я решил все-таки прочитать, что это за зверь. Прочитав пару-тройку статей, я усвоил для себя основные аспекты работы технологии и облегченно выдохнул, прочитав, что данная технология — удел гипервизоров и к транспорту имеет косвенное отношение (хотя, как оказалось позже отношение VxLAN к транспорту имеет самое, что ни на есть прямое). После чего про технологию благополучно забыл и вернулся я к ней снова только через год, когда начал погружаться в EVPN — большинство статей и мануалов были именно о симбиозе EVPN и VxLAN. Литературы по данной технологии много, особенно если вы владеете английским. Я же попробую в данной статье рассказать об основах работы данной технологии и показать на практике — как это настраивается и работает. Но начнем с MPLS…

О чём статья

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

Дайте код!

X = np.array([ [0,0,1],[0,1,1],[1,0,1],[1,1,1] ])
y = np.array([[0,1,1,0]]).T
syn0 = 2*np.random.random((3,4)) - 1
syn1 = 2*np.random.random((4,1)) - 1
for j in xrange(60000):
    l1 = 1/(1+np.exp(-(np.dot(X,syn0))))
    l2 = 1/(1+np.exp(-(np.dot(l1,syn1))))
    l2_delta = (y - l2)*(l2*(1-l2))
    l1_delta = l2_delta.dot(syn1.T) * (l1 * (1-l1))
    syn1 += l1.T.dot(l2_delta)
    syn0 += X.T.dot(l1_delta)

Слишком сжато? Давайте разобьём его на более простые части.

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

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

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

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

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

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

Доброго дня

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

Кому интересно — добро пожаловать под кат.

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

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

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

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

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

В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

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

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

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

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

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

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

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

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

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

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

О том, как мы работали по 10 часов в сутки без выходных, получили инвестиции, прошли во ФРИИ, набрали более ста тысяч пользователей в США, нас хотел купить Sports Illustrated, но в итоге мы закрыли компанию.