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



Backend для мессенджера написан на Go, поэтому и примеры будут на этом языке. Не желая изобретать велосипед, мы решили взять за основу XACML — стандарт для ABAC (Attribute-Based Access Control) — и максимально упростили его, чтобы он подходил для нашей задачи. Хотим отметить, что мы не ставили перед собой цель написать собственную реализацию XACML. Он был взят как пример работающей системы, из которого мы могли бы извлечь нужный для нас опыт.

Для знакомства с XACML и ABAC есть отличные статьи:

Знакомство с XACML — стандартом для Attribute-Based Access Control
Подходы к контролю доступа: RBAC vs. ABAC

Базовые объекты системы и интерфейс AttributeCalculater

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

type AttributeCalculater interface {
   Counter() (AttributeCalculater, error)
   Equally(Getter) bool
   Belong(Getter) bool
   GetType() string
   GetValue() (AttributeCalculater, error)
   GetValueField(string) (AttributeCalculater, error)
   GetInt() (int, error)
   GetBool() (bool, error)
   GetString() (string, error)
}

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

Правило (rule)

Правило — это самый простой объект в системе, который используется для описания бизнес-правил. Вот его структура:

type rule struct {
   Name      string
   Condition condition
   Effect    ruleEffect
}

func (r *rule) calculate(cntx *Context) calculateResult {}

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

type Context struct {
       Object     AttributeCalculater
   Subject    AttributeCalculater
   Target     Action
}

Контекст состоит из объекта (object) — сущности, которая реализует интерфейс AttributeCalculater и с которой система доступа выполняет какие-то действия, субъекта (subject) — сущности, которая так же поддерживает интерфейс AttributeCalculater и обычно является пользователем, желающим выполнить определенное действие в приложении. Цель (target) является enum'ом, в котором перечислены все возможные действия, поддерживающиеся системой доступа. Например: добавить пользователя в переписку, написать сообщение, назначить админа переписки и т.д.

Name (имя) правила нужно прежде всего для человека, который с ним работает — на сам процесс вычисления оно никак не влияет.

Effect (эффект) показывает, как будет обрабатываться результат вычисления условия. Эффект может быть разрешающим (permitEffect) или запрещающим (denyEffect). Скажем, если результат вычисления условия — true, а эффект задан как permitEffect, то результат вычисления правила также будет true. Если же эффект прописан как denyEffect, то результатом правила будет false.

Condition (условие) — самая главная часть правила, в которой, собственно, описывается и высчитывается условие для него.

type condition struct {
       FirstOperand  Attribute
   SecondOperand Attribute
   Operator      conditionOperator
}

func (c *condition) calculate(cntx *Context) (bool, error) {}

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

Operator (оператор) отвечает за то, как сравниваются два операнда. Принимает следующие значения:

• equally - проверяет, равны ли операнды.
• notEqually — проверяет, не равны ли операнды.
• belong — проверяет, есть ли между операндами какое-то отношение. Конкретная логика зависит от реализации интерфейса AttributeCalculater, который должны реализовать объекты, работающие с системой доступа. Подробнее об этом расскажем ниже.
• notBelong — противоположность belong.

Как видно из структуры, условие может быть вычислено только для двух операндов, то есть в одном правиле не предполагается рассмотрение сложных use case'ов, которые возникают при работе с системой доступа. Для этого используются комбинации правил.

Тип данных операндов — это Attribute (атрибут). В нем находится информация вычисления условий.

type Attribute struct {
       NameObject string
   Field      string
   Type       TypeAttribute
   Object     AttributeCalculater
}

func (a *Attribute) getValue(c *Context) (AttributeCalculater, error) {}

Метод getValue возвращает значение атрибута. Возвращается оно в виде объекта, у которого реализован интерфейс AttributeCalculater.

NameObject (имя объекта), у которого при вычислении атрибута берется значение из поля Field. Сам же объект находится в поле Object.

Политика (politic)

Политики используются для описания бизнес-правил с одним или несколькими правилами.

type politic struct {
   Name             string
   Target           Action
   Rules            []rule
   CombineAlgorithm combineAlgorithm
}

func (p *politic) calculate(cntx *Context) calculateResult {}

Name (имя) у политики, как и у правила, нужно только для человека, который с ней работает.

Targer (цель) используется для поиска политик. Для простоты в нашей системе у каждой цели своя политика.

Rules (правила) — это набор простых правил, которые дополняя друг друга могут описывать сложные бизнес-правила.

CombineAlgorithm (алгоритм комбинирования) правил указывает на то, как обрабатывать результаты вычисления правил политики. В XACML эти алгоритмы могут быть достаточно сложными, но в нашем случае все эти изыски не нужны. Поэтому у нас пока всего два простых алгоритма permitIfAllPermitted (разрешить, если все разрешили) и permitIfOnePermitted (разрешить, если один разрешил). Например, если стоит алгоритм permitIfAllPermitted, то результат вычисления политики будет положительным только при том условии, что все правила в этой политике также имели положительный результат.

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

https://habrahabr.ru/post/329760/

https://habrahabr.ru/post/329778/

Предыстория

Уже много лет мы помогаем нашим клиентам отправлять потребителям хорошие, информативные и человеческие письма. В них вместо сухого “Добрый день” мы пишем “Здравствуйте, Никита!”, а вместо “Ваш баланс пополнился” сообщаем “вы получили 25 баллов”. Но маркетологи становятся все изобретательнее, и современное письмо от интернет-магазина должно выглядеть так:

И мы хотим уметь генерировать такие письма автоматически.

Наш старый, проверенный временем шаблонный движок умеет вставлять в нужные места письма параметры, подставлять вместо отсутствующего значения что-то по умолчанию и писать “1 рубль, 2 рубля, 5 рублей”, причем делает это хорошо. Но он не предназначен для сложных ветвлений, циклов и любой другой сложной логики. Поэтому для формирования сложных писем как на картинке нам приходилось прибегать к коду на C#, и выглядело это так:

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

• вывод простых параметров
• вывод сложных многоуровневых параметров (Recipient.Address.City.Name)
• условия
• циклы
• арифметические операции

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

• внятные сообщения об ошибках
• валидация используемых в шаблоне параметров
• расширяемость (возможность добавлять свои функции)

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

• прекомпиляция шаблона
• возможность переиспользования шаблона и потокобезопасность

Мы рассмотрели несколько доступных шаблонных движков, начиная Liquid и заканчивая Mustache, и все они немного со странностями. Кто-то при ошибке не падает с исключением, а просто рендерит пустую строку. Где-то синтаксис такой, что мы, будучи программистами, не смогли понять, как написать условие. Мы всерьез подошли к безумной идее использовать близкий и понятный нам Razor для формирования писем, но отказались от неё из-за досадной мелочи: получалось, что составитель шаблона рассылки мог выполнять произвольный .NET-код в процессе, отправляющем письмо.

И конечно же, в итоге мы решили написать свой шаблонный движок. Со статической типизацией и цепочками фильтров.

Дизайн языка

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

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

Мы остановились на таком варианте:

Идея разделять выводящие инструкции ${ … } и не выводящие, служебные инструкции @{ … } навеяна имплицитными и эксплицитными выражениями из Razor. Попробовали посмотреть, как это будет выглядеть в реальной HTML-вёрстке, и да, так оказалось лучше и нагляднее.

Позже вспомнили, что такой же синтаксис используется в TypeScript для string interpolation (а в C# – другой, но тоже похожий). Стало приятно: если Андерс Хейлсберг посчитал это хорошим синтаксисом, то мы на верном пути.

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

В итоге остановились на таком синтаксисе:

Осталось всего ничего: сдуть пыль с “книги дракона” и реализовать лексический разбор, синтаксический анализ, семантический анализ, а потом обеспечить генерацию выходного результата – письма.

Парсинг и ANTLR

Всем должно быть очевидно, что придуманный нами язык по классификации Хомского описывается контекстно-свободной LL-грамматикой, для разбора которой, соответственно, достаточно реализовать LL(*)-парсер. И тут же мы столкнулись с небольшой проблемой: мы почти ничего в этом не понимаем и не умеем.

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

На этом месте мы пошли и ввели в гугле в строку поиска чит-код: AN­TL­R. Эффект не был мгновенным, но после пары дней, потраченных на чтение документации и эксперименты, мы получили такой прогресс, на который при ручной разработке ушло бы несколько недель. Итак, что такое Antlr и что он берет на себя?

ANTLR (ANother Tool for Language Recognition) – открытая библиотека, написанная Терренсом Парром, преподавателем университета Сан-Франциско и автором десятка с лишним научных статей о формальных грамматиках и их разборе. Её понемногу используют для задач парсинга ребята из Google, Oracle и Microsoft (например, в ASP.NET MVC). Antlr полностью берёт на себя лексический и синтаксический разбор текста, руководствуясь формальным описанием грамматики языка.

Конечно, не всё было безоблачно. При близком знакомстве Antlr оказался java-утилитой, которую нужно запускать из командной строки, пытаясь подобрать правильные аргументы из противоречащих друг другу статей документации, чтобы она сгенерировала C#-код, на который будет ругаться StyleCop. Документация нашлась, но не всё, что реализовано в утилите, описано в документации, и – вот это было ударом – не всё, что описано в документации (официальной книге от автора библиотеки) уже реализовано в утилите. Поддержка C# оказалось не такой полной, как поддержка Java, а из работающих вспомогательных инструментов мы нашли только плагин к эклипсу.

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

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

Грамматика языка: лексические правила

Описание грамматики ANTLR складывается из набора рекурсивных правил. Любому, кто на первом-втором курсе познакомился с БНФ, диаграммами Вирта или другими способами описания формальных языков, эта идея будет близка и понятна.

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

Взялись за правила лексера. Самая важная задача – сделать так, чтобы мы распознавали наш язык только внутри блоков ${ ... } и @{ .... }, а остальной текст письма оставляли неизменным. Иными словами, грамматика нашего языка – островная грамматика, где текст письма – неинтересный для нас “океан”, а вставки в фигурных скобках – интересные “острова”. Блок океана для нас абсолютно непрозрачен, мы хотим его видеть одним крупным токеном. В блоке острова мы хотим максимально конкретный и мелкий разбор.

К счастью, Antlr поддерживает островные грамматики из коробки благодаря механизму лексических режимов. Сформулировать правила, по которым мы делим текст на “океан” и “острова” было не совсем тривиально, но мы справились:

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

В режиме “внутри инструкции” симметричное правило, которое при встрече с закрывающей фигурной скобкой возвращает парсер в основной режим.

Ключевые слова “popMode” и “pushMode” намекают нам, что есть у парсера есть стек режимов, и они могут быть вложенными с какой-то внушительной глубиной, но для нашей грамматики достаточно переходить из одного режима в другой и потом возвращаться обратно.

Осталось описать в “океане” правило, которое будет описывать всё остальное, весь текст, который не является входом в режим инструкций:

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

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

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

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

Такое правило, конечно же, может существовать только в режиме “острова”, чтобы мы не вырезали пробелы и переносы строк в тексте письма.

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

и заканчивая ключевыми словами (IF, ELSE, AND и другие):

Регистронезависимость выглядит страшновато, но в документации резонно написано, что лексический разбор – штука точная и подразумевающая максимально явное описание, и эвристике по определению регистра во всех алфавитах мира там не место. Мы не стали с этим спорить. Зато у нас else if воспринимается как один токен (что удобно), но при этом он не elsif и не elseif, как это бывает в некоторых языках.

Откуда-то из глубин воспоминаний о первом и втором курсе, растревоженных словами про БНФ и диаграммы Вирта, всплывает понимание, как описать IDENTIFIER так, чтобы идентификатор мог начинаться только с буквы:

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

Грамматика языка: синтаксические правила

Структура любого письма в нашем шаблонизаторе проста и напоминает зебру: статические блоки вёрстки чередуются с динамическими. Статические блоки – это куски вёрстки с подстановкой параметров. Динамические – это циклы и ветвления. Мы описали эти основные блоки таким набором правил (приведен не полностью):

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

Разобрав текст этим набором правил, получили что-то подобное:

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

Здесь мы описываем сложное условное высказывание, в котором обязателен блок if, может быть несколько блоков else if и может быть (но не обязательно) один блок else. В блоке If внутри знакомый нам templateBlock – тот самый, который может быть чем угодно, в том числе другим условием.

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

От дерева к дереву

Результат работы Antlr начиная с 4 версии – парсер, который превращает текст в так называемое concrete syntax tree, оно же парсерное дерево. Под concrete подразумевается, что дерево содержит в себе всю информацию о синтаксисе, каждое служебное слово, каждую фигурную скобку и запятую. Это полезное дерево, но не совсем то, которое нужно для наших задач. Основные его проблемы – слишком сильная связанность с синтаксисом языка (который неизбежно будет меняться) и совершенная неосведомленность о нашей предметной области. Поэтому мы решили обходить это дерево ровно один раз и строить на его основе своё дерево, которое ближе к abstract syntax tree и удобнее в дальнейшем использовании.

Требования к дереву такие:

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

Упрощенный интерфейс вершины нашего дерева в итоге выглядит примерно так (набор потомков и логика их обхода слишком разные для разных узлов, поэтому в общем интерфейсе их нет):

internal interface ITemplateNode
{
    void PerformSemanticAnalysis(AnalysisContext context);

    void Render(StringBuilder resultBuilder, RenderContext renderContext); 
}

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

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

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

Например, для обхода условий внутри @{ if } … {else if } … {else } .. @{ end if } мы используем специальный визитор:

internal class ConditionsVisitor : QuokkaBaseVisitor
{
    public ConditionsVisitor(VisitingContext visitingContext)
        : base(visitingContext)
    {
    }

    public override ConditionBlock VisitIfCondition(QuokkaParser.IfConditionContext context)
    {
        return new ConditionBlock(
            context.ifInstruction().booleanExpression().Accept(
                new BooleanExpressionVisitor(visitingContext)),
            context.templateBlock()?.Accept(
                new TemplateVisitor(visitingContext)));
    }

    public override ConditionBlock VisitElseIfCondition(QuokkaParser.ElseIfConditionContext context)
    {
        return new ConditionBlock(
            context.elseIfInstruction().booleanExpression().Accept(
                new BooleanExpressionVisitor(visitingContext)),
            context.templateBlock()?.Accept(
                new TemplateVisitor(visitingContext)));
    }

    public override ConditionBlock VisitElseCondition(QuokkaParser.ElseConditionContext context)
    {
        return new ConditionBlock(
            new TrueExpression(),
            context.templateBlock()?.Accept(
                new TemplateVisitor(visitingContext)));
    }
}

Он инкапсулирует в себе логику создания объекта ConditionBlock из фрагмента синтаксического дерева, описывающего ветку условного оператора. Поскольку внутри условия может быть произвольный кусок шаблона (грамматика-то рекурсивная), управление для разбора всего внутри снова передается универсальному визитору. Наши визиторы связаны рекурсивно примерно так же, как и правила граммматики.

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

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

И в результате получаем из такого дерева

такое

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

Осталось совсем немного – обойти его несколько раз. И первый, обязательный обход – это обход для семантического анализа.

Получение списка параметров и типизация

Одна из ключевых задач нашего шаблонизатора – умение найти в тексте письма все используемые в нем параметры. Цель понятна: валидировать и не давать сохранить шаблон, в котором встречаются параметры, которые мы не сможем подставить в письмо. Например, Recipient.Email мы знаем, а Recipietn.Eamil – нет. Для нас важно, чтобы отправитель узнал об ошибке в шаблоне сразу при его сохранении, а не при попытке отправить письмо.

Однако это не единственное направление валидации параметров. Хотим ли мы давать написать в письме ${ Recipient.Email + 5 }, зная, что Email у нас в системе – строковое поле? Кажется, нет. Значит, мы должны не только найти все параметры в письме, но и определить их тип. На этом месте мы обдумали типизацию и поняли, что она у нас статическая (что хорошо), но при этом неявная (что удобно пользователю, но неудобно нам). Ощутили мимолетный импульс заставить менеджера декларировать в начале письма все параметры явно, указывая тип. Удобство пользователя победило, импульс подавили. Придется определять тип “на лету” исходя из контекста.

Система типов нашего шаблонизатора выглядит так:

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

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

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

Глядя на этот шаблон, мы можем сказать, что у потребителя должен быть массив продуктов, а каждый продукт имеет цену и массив категорий, а у каждой категории должен быть как идентификатор Id, так и название Name. Теперь достаточно спросить нашу систему, есть ли в ней параметры такой структуры, и никаких сюрпризов при отправке не будет. Или почти никаких.

Рендеринг

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

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

Вывод такого значения приведет к ошибке, если B = 0. Заманчивая идея – усилить систему типов для таких случаев, но легко вообразить и такой сценарий, где всё совсем-совсем непредсказуемо:

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

• Иметь reasonable defaults (при выводе null-значения выводить пустую строку, при использовании в условии null-значения возвращать false, при делении на ноль работать с NaN и так далее)
• Соблюдать принцип fail fast

Решили так: отправить кривое письмо гораздо хуже, чем не отправить никакое вообще. Отправленное уже не вернешь, а не отправленное можно исправить и повторить. Поэтому fail fast, понятный, простой и без эвристик, нам подходит гораздо лучше.

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

internal class ToUpperTemplateFunction : ScalarTemplateFunction
{
    public ToUpperTemplateFunction()
        : base(
            "toUpper",
            new StringFunctionArgument("string"))
    {
    }

    public override string Invoke(string argument1)
    {
        return argument1.ToUpper(CultureInfo.CurrentCulture);
    }
}

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

Итоги

Приняв примерно сотню мелких и больших решений, мы наконец отрендерили своё первое письмо с циклами и условиями. Мы написали свой собственный шаблонный движок, практически с нуля, и в процессе поняли, что синдром Not invented here – плохо, но если правда не находится ничего, что удовлетворяет нашим требованиям, надо брать и делать своё.

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

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

Ссылки:

1. Описание шаблонизатора с примерами использования в блоге Mindbox
2. ANTLR

https://habrahabr.ru/post/329772/

Читая комментарии к статье о конференции OS Day 2017, я как разработчик одной из представленных в России ОСРВ Embox, был немного в шоке. Нет, в России все знают, что кроме BolgenOS и каких-то очередных распилов у нас ничего не умеют!
Но во-первых, мероприятие проходило в главном здании РАН, и вряд ли такая солидная организация пропустила бы поделки школьников, а во-вторых, комментарии писали пользователи хабра, а значит, технически грамотные люди, и в отсутствии у них осведомлённости об Alt Linux, KolibriOS, PhantomOS, ReactOS вряд ли можно усомниться. Я решил не вмешиваться в обсуждение, а написать собственное мнение о происходившем по итогам этой конференции.

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

Безопасность, безопасность и еще раз, безопасность

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

Не буду рассказывать о нескольких докладах ФСТЭК, в том числе зам директора ФСТЭК Виталия Лютикова, поскольку не являюсь специалистом в области регламентирующих документов, но данные доклады вызвали довольно большой интерес у собравшихся, а значит, такие проблемы действительно интересны.

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

Товарищи из Лаборатории Касперского меня, как разработчика встроенных систем, порадовали тем, что показали работу на железке с процессором imx6 (ARMv7). Их доклад, как и следовало ожидать, был посвящен операционной системе KasperskyOS. Нам показали коробку с не очень понятным содержимым, зато объяснили идею предлагаемого решения.
Как я понял, она заключалась в следующем:

• На разрабатываемое ПО накладываются ограничения: по сути дела, прикладное ПО может предоставлять только некий сервис с заранее описанным интерфейсом. В принципе, под это подходит любая микроядерная архитектура.
• Выделяется некий сервер (сервис) безопасности, который пропускает через себя все IPC-сообщения, или, по сути, запросы к сервисам.
• В сервисе безопасности есть доступ к дескрипторам безопасности, которые можно наложить на любой публичный вызов в остальных сервисах. Ограничения для дескрипторов, разрабатываются на DSL (специализированном языке), отдельно от основной бизнес-логики.

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

СПО и кооперация

Одним из первых выступал директор ИСП РАН Арутюн Аветисян.
Мне доклад понравился, хоть там и были рекламные нотки. Один из ключевых тезисов доклада, как я понял, заключался в том, что институт имеет богатый опыт именно в работе с СПО. Поскольку системное ПО, да и не только системное, должно быть мирового качества, необходимо объединяться и совместно развивать СПО, так как отдельным компаниям и институтам это не под силу.

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

Импортозамещение

Это, наверное, самое часто упоминаемое и наиболее провокационное направление!

Например, в своем докладе Сергей Аносов заявил, что Sailfish OS — отечественная система потому, что внесена в реестр отечественного ПО, и в подтверждение привёл сертификат (можно посмотреть в презентации). А Егор Васильев сообщил, что ГосЛинукс уже год не вносят в этот самый реестр! В принципе, это и не нужно, поскольку его невозможно купить, то есть он бесплатен, его можно скачать и, получив разрешительные документы, использовать.

Конечно, одними из самых активных и докладчиков и “вопросозадавателей” были сотрудники Базальта (бывший Альт Линукс). Порой они доходили до лёгкого троллинга, ведь у них оригинальная базовая платформа, а те, кто делает на Debian, CentOS и других, зависят от соответствующих комьюнити.

Вообще, на конференции присутствовали пользователи и разработчики большинства популярных семейств дистрибутивов Linux. Фишкой стала попытка некоторых компаний войти в кооперацию, например, компания Mellanox Technologies сделала прототип коммутатора на ОС ALT.

Ещё одной темой стала борьба с Windows. Точнее, не борьба, а как раз взаимодействие: кто-то жаловался на лицензионные шрифты и офисные программы, кто-то предлагал использовать Mono для запуска приложений, но, наверное, отмечу только доклад Алексея Коптева из компании РедСофт. Он рассказал про проблему с криптобиблиотекой под wine и как она была решена. Запомнился доклад тем, что разработчики предпочли не нарушать лицензионные соглашения, а нашли корректный способ решить эту проблему, написав соответствующий патч. Кроме того, выяснилось, что такая же проблема есть у многих компаний, и уже в кулуарах соратники по проблеме долго обсуждали данную тему.

Мобильные платформы и корпоративный сегмент

На конференции были представлены две “отечественные” платформы: Тайзен.ру и уже упомянутая ранее Открытая мобильная платформа (Sailfish Mobile OS RUS). Платформенность заключается в том, что на территории России развернута собственная инфраструктура и для приложений, и для сборки и разработки.

На мой взгляд, Тайзен выглядел сильно лучше. Это не удивительно, ведь за ним стоит вся мощь компании Samsung. Основная часть доклада была посвящена презентации новой части Tizen для IoT решений Tizen-RT. Презентовал её Вячеслав Тыртов, ведущий инженер Samsung R&D Institute RUS. То есть, сотрудник Самсунг, а не Тайзен. Новая ОС основана на NuttX, и часть доклада была посвящена именно ей.

Чтобы не быть уличённым в предвзятости, отмечу, что Sailfish OS предлагают корпоративные решения с закрытыми или не очень магазинами приложений и вообще частной инфраструктурой.

Наука, религия и бред сумашедшего

Эта секция, даже несколько секций, объединяли доклады, которые предлагали какие-то новые идеи и концепции в области операционных систем. Сама идея, что в ОСестроение можно привнести что то новое и строить ПО по другим принципам, время от времени возникает, ведь в этой области очень мало изменений со времен UNIX и микроядра.

Конечно, основное место в плане новых концепций у нас занимает PhantomOS. Было два доклада. Один от автора ОС Фантом Дмитрия Завалишина, он был посвящен особенностям архитектуры “Эльбрус-2000” (E2K), на которую сейчас происходит портирование данной ОС. Второй доклад был от профессора Иннополиса Евгения Зуева. Его доклад был посвящен возможным направлениям развития ОС Фантом. На основе ОС Фантом и платформы Эльбрус с помощью рабочей группы в Иннополисе планируется создать некий продукт, который можно будет внедрить не только в учебный процесс.

Очень порадовал сумасшедший ученый преподаватель МГУ Дмитрий Черухин заявивший, что он написал свою ОС с нуля, имеющую собственный сетевой стек протоколов и на этой основе крутится веб-сервер для тестовых заданий студентов (адрес сервера можно увидеть на приведенной выше странице докладчика). Существует репозиторий на github. Называется данная ОС LDuS (Long Dmirtiy u Svetlana). Построена она по оригинальным принципам. Если интересно, можно посмотреть его презентацию.

Станислав Братанов из компании Интел тоже представил оригинальную концепцию Ресурс-Владелец-Услуга (Resource-Owner-Service, ROS). Данная ОС был разработана в 1999 году и в 2009 получила своё новое развитие как ОС для сенсорных сетей. Я уже читал статью о данной разработке на хабре, но было интересно услышать об этом вживую. Правда, многие слушатели доклада сошлись на том, что в нём описывается Erlang.

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

Бортовые системы

Как выразился один из докладчиков, данная секция возникла благодаря санкциям, то есть наши компании столкнулись с тем, что даже закупленные ОСРВ остались без поддержки. Пришлось что-то придумывать по ходу дела.

Представлены были JetOS от консорциума: ГосНИАС ( докладчик Юрий Солоделов), ИСП РАН (докладчик Николай Пакулин), Digital Zone. И МОС-ОП от компании Вайс-Техника (докладчик Алексей Фролов). Работу JetOS можно было посмотреть на стенде технологий.

Ещё немного новых ОС

Было представлено ещё две новых закрытых ОС.

Валерий Егоров из компании Криптософт представил QP ОС. И заявил, что компаний разработала не только ОС, но и гипервизор, компилятор и машину .NET.

Павел Бойко из компании АстроСофт представил ОСРВ МАКС для интернета вещей. Основной фишкой этой ОСРВ, по мнению докладчика, является распределённая общая память.
Поскольку обе представленные разработки являются проприетарными, у слушателей возник, как мне показалось, скепсис. Особенно к ОСРВ МАКС, в кулуарах даже прозвучало, что это хорошая студенческая работа, но предлагать её в качестве продукта, за который берут деньги, несколько странно.

Резюме

Закончить я бы хотел словами товарища из Самсунга, той самой компании, которая взяла за основу своей платформы, не наш замечательный Embox, а забугорный NuttX:
“Хорошо, что в нашей стране хоть что-то в этой области стали делать”.

https://habrahabr.ru/post/329776/

Администраторы небольших и средних компаний часто не используют большинство функций своего корпоративного файрвола. По статистике, основных причин этого несколько. В 25 % случаев главные настройки выполнены, а на другие у администратора не хватает времени. Еще в 34 % случаев они не справились с настройками. И в 41 % случаев все имеющиеся функции попросту не требуются им. Из этого можно сделать вывод: шлюз безопасности нужно выбирать только в соответствии со своими собственными задачами и возможностями, не ориентируясь на весь перечень функций.

Для требований большинства компаний – как малых и средних, так и крупных с географически распределенной инфраструктурой – отлично подойдут шлюзы безопасности Cisco Meraki MX. Они просты в настройке, не требуют присутствия администраторов безопасности в отдаленных филиалах и вместе с тем используют те же наборы сигнатур, что и топ-решения Cisco Firepower. ,

Рассмотрим несколько основных вариантов использования Meraki MX в организации. Их можно настроить всего в 4 клика мышкой на интуитивно понятной панели Meraki Cloud без сложных настроек и командной строки.

Связь с новым филиалом – AutoVPN

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

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

Устройства семейства Meraki MX обладают необходимым набором инструментов для создания подобных VPN-туннелей в автоматическом режиме.

Настройка в 4 клика

1. Выбрать режим работы VPN-концентратора (в центре выбран режим Hub, так что нажимаем Spoke).
2. Для Spoke выбрать режим туннелирования Split, чтобы использовать VPN-туннель только для трафика в центральный офис, а интернет-трафик выпускать непосредственно «в свет».
3. Все подсети уже подсчитаны, необходимо только выбрать, какие могут использовать VPN (указать напротив yes/no).
4. Сохранить. Теперь облако Meraki само согласует адресацию и параметры туннелей IPsec AES128 и распространит данные о VPN-маршрутах на устройстве MX в сети (рис. 1).


Рисунок №1

Защита от угроз

Любая сеть являет собой мишень для вторжений и вредоносных атак. Подобные вторжения становятся виной утечек конфиденциальной информации, остановки критических для бизнеса приложений и даже аварийных остановок предприятий. Meraki MX оснащен продвинутыми и легконастраиваемыми инструментами для противостояния подобным угрозам. Тандем IPS на SourceFire Snort, Cisco Advanced Malware Protection и каждодневного обновление базы данных сигнатур, защитят корпоративную сеть от возможных рисков. А система ретроспективного анализа позволит предпринять меры даже в случае прохождения 0Day атак.

Настройка в 4 клика

1. Включить антивирусное сканирование (Malware prevention — enabled).
2. Включить защиту от несанкционированного доступа на базе SourceFire (Intrusion detection and prevention – выбрать Mode Prevention).
3. Выбрать из трех предустановленных наборов правил IPS от наиболее лояльного до рестриктивного (Connectivity/Balanced/Security).
4. Сохранить. Теперь вы защищены и можете просматривать аналитику (рис. 2).


Рисунок №2

Допустимое использование интернета

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

Настройка в 4 клика

1. Выбрать категории web-сайтов, которые необходимо заблокировать (рекомендуем блокировать Adult, Bot Nets, Confirmed SPAM Sources, Illegal, Malware Sites, Phishing, Proxy Avoidance, SPAM URLs, Spyware).
2. Включить фильтрацию поисковых запросов (Web search filtering – enabled).
3. Включить фильтрацию YouTube (YouTube for schools – enabled).
4. Сохранить. Теперь у сотрудников вашей компании (или учеников вашей школы) ограничен доступ к сайтам, которые непозволительно использовать на рабочем месте (рис.3).


Рисунок №3

Шейпинг и приоритезация трафика

В настоящее время вместе с планомерным увеличением скоростей передачи данных в телекоммуникациях увеличивается доля интерактивного трафика, крайне чувствительного к параметрам среды транспортировки. Поэтому задача обеспечения качества обслуживания (Quality of Service — QoS) становится все более актуальной. Нам необходимо, что бы бизнес-критические приложения имели приоритет над различными мультимедийными и не страдали от заполнения канала.

Настройка в 4 клика

1. Выбрать параметры допустимой загрузки входного и выходного трафика для обоих WAN-аплинков (у вас также есть возможность подключить 3G/4G-модем как дополнительный аплинк для обеспечения отказоустойчивости).
2. Включить уравнитель нагрузки между аплинками (Load Balancing – enabled).
3. Включить правила шейпинга трафика. Для VoIP and Videoconferencing установить приоритет High. Для категорий Peer-to-peer, Online backup, Video & Music выставить ограничение по полосе пропускания и приоритет Low.
4. С такими настройками даже в случае ограниченной пропускной способности канала ваши пользователи не заметят снижение скорости передачи данных: канал для бизнес-приложений не будет засоряться исходящим трафиком. Эти функции доступны на всех шлюзах безопасности Cisco Meraki MX, осталось лишь выбрать необходимую вам модель в зависимости от ваших нужд, наличия WiFi, PoE, специфических портов (рис. 4, 5).


Рисунок №4


Рисунок №5

В России решение Cisco Meraki в данный момент не доступно для заказа.
В Украине, Азербайджане, Грузии Cisco Meraki можно купить непосредственно у локальных партнеров Cisco.

https://habrahabr.ru/post/328862/

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

При том, что системы контроля и управления доступом (СКУД) применяются сегодня в большинстве производственных компаний, государственных структур и бизнес-центров, в своей массе эти решения базируются на картах RFID старого поколения. Привычный всем пластмассовый бейдж HID Prox служит спутником сотрудников при перемещении по разным зонам, но для всех уже очевидно, что одна RFID-карта не обеспечивает надлежащего уровня безопасности, ведь ее можно украсть, потерять, забыть или просто подделать.

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



Именно потому, что карту можно украсть, многие компании используют методы фотоверификации. Обычно они реализованы в ручном режиме, когда сотрудник службы безопасности сверяет фотографию на документе с лицом человека, использующего данный пропуск. Но человеку требуется значительное время, чтобы проверить соответствие, да и ошибки не исключены. А по результатам исследований NIST (National Institute of Standards and Technology), текущий уровень развития алгоритмов автоматизированной фотоидентификации, вышедших из практики нейронных сетей, позволяет значительно повысить точность и свести к считанным долям секунды скорость распознавания.

Виды биометрической идентификации

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

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

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

Внедрять или не внедрять?

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

Тем не менее, когда пользователи получают выбор, они начинают видеть и ценить преимущества биометрической идентификации. Например, в технопарке Набережных Челнов была реализована однофакторная идентификация, но с возможностью выбора – посетители могут использовать либо RFID-карту, либо отпечаток своего пальца. Наблюдая за этим проектом, мы заметили, что изначально вторым методом пользовалось лишь 5-10% посетителей, но через год соотношение оказалось 50x50. Возможно, это и есть лучший способ дать персоналу привыкнуть – предоставить ему выбор, пользоваться старой системой или новой.

Конвергентные системы

Но пока многие размышляют, как усилить многофакторную аутентификацию, технологии продолжают развиваться, и биометрия используется одновременно для систем СКУД и в информационных системах. Мы считаем, что инструменты IAM (Identity Access Management), скоро будут интегрированы со средствами обеспечения для физического доступа.

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

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

Стоимость внедрения

Итак, если у вас уже есть СКУД, переход на биометрическую идентификацию, как правило, подразумевает замену считывающих устройств. Если вы задумываетесь о дактилоскопии, то вопрос решается в пределах $200 за один терминал, но зато пропадает необходимость поддерживать устаревшие пропуски и отвечать за риски безопасности.

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

https://habrahabr.ru/post/329774/

Вирусы шифровальщики не первый год сотрясают ИТ общественность последствиями своей подпольной работы. Скрываясь за ссылкой в email или в JavaScript коде на странице веб сайта, они молчаливо инсталлируются на рабочие компьютеры или сервера и начинают тихо зашифровывать всю информацию. После окончания шифрования, некоторые просто удаляют ключ шифрования, а не которые требуют выкуп, но далеко не все заплатившие выкуп получают ключ шифрования. Как же с ними можно бороться? Самое главное средство борьбы – быть подготовленным к борьбе.

Резервное копирование

Как в самых больших, так и в маленьких организациях рабочие файлы располагают на общедоступном файловом хранилище, чтобы все могли ими пользоваться. Централизация хранения даёт удобство для совместной работы нескольким людям над одними и теми же файлами, но это налаживает и ответственность по защите такой информации. Естественно для борьбы с вирусами-шифровальщиками необходимо регулярно выполнять резервное копирование по схеме 3-2-1. Резервные копии важно хранить отдельно от основной системы. Но полное восстановление, во-первых, может быть достаточно длительным, а во-вторых резервное копирование как не крути выполняется не каждый час, и теряется вся новая информация (большой RPO).

Снепшоты для спасения

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

Как снепшоты не должны работать

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

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

Снепшоты в операционной системе ONTAP для хранилищ NetApp так не работают. Они были впервые реализованы в операционной системе ONTAP, как часть файловой системы WAFL в 1993 году, эти технологии апробированы временим и сотнями тысяч компаний по всему миру. Кстати само слово «снепшот» (Snapshot ™) является зарегистрированной торговой маркой компании NetApp, а эта технология снепшотирования запатентована. Чтобы удостовериться в том, как работают снепшоты WAFL можно бесплатно скачать на тестовый период виртуальную машину с образом хранилища ONTAP.
mysupport.netapp.com/NOW/cgi-bin/software/?product=ONTAP+Select&platform=Deploy+Install

Автоматизация восстановления

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

Репликация снепшотов

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

Снепшоты как индикатор заражения Ransom

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

WORM

Технология Wright Once Read Many или WORM, таже известна и под другими названиями, к примеру SnapLock построенная на базе снепшотирования, позволяет залочить данные на длительный срок от изменений. К примеру можно хранить конфиги от разнообразных устройств, к примеру свичей, роутеров и прочее. Подобного рода файлы редко если вообще меняются в течении жизни устройства, а харнилища с поддержкой WORM надежное место для хранения фажных файлов-настроек для инфраструктуры.

Антивирусная защита NAS

Ну и конечно же возможность проверки файлов на строне хранилища тоже будет не лишней.

Вывод

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

Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.

https://habrahabr.ru/post/329746/

В первой части статьи про нашу систему мониторинга мы рассказали, какие организационные и технические проблемы заставили нас заняться расширением функционала Zabbix. В этой — покажем, как именно нам удается «переваривать» миллионы ежесекундно снимаемых отсчетов и превращать их в 40K+ values-per-second без потери ключевой информации.

Новый сервер? Автоматом

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

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

Когда админы разворачивают новый сервер, они подключают его в Spacewalk (бесплатный аналог Red Hat Network Satellite). Эта полезная штука разворачивает на сервере конфиги и ПО, включая все необходимое для мониторинга. В том числе устанавливает наш пакет sbis3mon-discovery-scripts – легковесную утилиту на Python, которая запускается «по крону» каждый час, сканирует сервер и отправляет данные о найденных сервисах в реестр обнаружения (Discovery Registry).

Таким образом, sbis3mon имеет возможность запрашивать из реестра данные о серверах и сервисах, которые можно мониторить. Теперь включить наблюдение за сервером и его сервисами можно в один клик, просто выбрав его из списка в админке.


Изображение кликабельно, открывается в текущей вкладке веб-браузера.

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

Конечно же, есть возможность добавить сервер и вручную или клонированием.

Включаемся!

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

• ssh – для сбора данных с Linux;
• postgresql – выполняет прямое подключение к базам через нативный протокол;
• redis – к redis;
• … и т.д.

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

Мы стараемся использовать доступные нативные интерфейсы сервисов для получения статистики. За исключением мониторинга Windows и IIS мы не используем агентов. Хотя сейчас есть идея, как избавиться и от них.

Плагин – основа конфигурации

После установки соединения плагин получает с сервиса конфигурацию: список его сущностей (список баз, перечень подмонтированных дисков, или активных сетевых интерфейсов, …).


Изображение кликабельно, открывается в текущей вкладке веб-браузера.

Список сущностей плагин отправляет в модуль zabbixSync, который отвечает за создание или синхронизацию в Zabbix’е «хоста» и описанных плагином структур: итемов, графиков, скринов (дашбордов) и триггеров. Да, вся визуализация и логика триггеров – тоже часть кода.

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

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


Изображение кликабельно, открывается в текущей вкладке веб-браузера.

Свет, камера… снова плагин!

Одновременно с синхронизацией с Zabbix через заданные интервалы начинается опрос заданных сервисов. Для каждого из соответствующих плагинов координатор формирует и отправляет на выполнение задачу.

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

Например, плагин мониторинга linux-сервера устроен примерно следующим образом:

• при разворачивании сервера через spacewalk на него сразу «заливается» ключ sbis3mon для доступа по SSH;
• при активации мониторинга коллектор получает задачу для linux-плагина * плагин устанавливает SSH-соединение с помощью NodeJS-модуля ssh2;
• в установившейся сессии запускаем на выполнение команду, которая сама будет отдавать нам все данные с нужной частотой:
  watch -n 1 cat /proc/meminfo # все, дальше парсим на приемнике
  

Правила съема. Метод sbis3mon

Обычно съем метрик практически в каждой системе происходит по принципу «спросил – узнал», и важно наличие самой возможности «спросить» что нужно. Когда же у вас высоконагруженная система, все меняется в корне.

Например, у нас была ситуация, когда в какой-то момент виртуальная машина, на которой жила база «под реальным highload’ом», критичным ко времени отработки каждого миллисекундного запроса, «вставала колом» на 2-3 секунды. Снимая данные по CPU раз в 15 секунд, мы просто не наблюдали этих проблем – они «проскакивали» между отсчетами.

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

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

Например, изначально мониторинг состояния и количества сетевых соединений у нас был реализован через netstat. И все было хорошо, пока не начали появляться серверы с десятками и сотнями тысяч активных соединений – диспетчеры на Nginx, шина сообщений на RabbitMQ, … В какой-то момент мы увидели, что выполнение команды «для мониторинга» просаживает CPU в разы относительно прикладной нагрузки! Пришлось срочно переделывать съем данных через ss.

«А вместо сердца – пламенный мотор!»

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

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

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


Изображение кликабельно, открывается в текущей вкладке веб-браузера.

Компрессия данных

В конечном счёте, полученные данные отправляются дальше – в модуль аппроксимации.

Понятно, что даже если мы снимаем данные посекундно, то ни Zabbix’у, ни смотрящему в него человеку, счастья от такой частоты нет совсем. Один «ляжет» под нагрузкой (мы ведь помним, что данные снимаются с нескольких тысяч серверов), у другого «вытекут глаза» от чехарды на графике.

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

Поскольку на своих графиках Zabbix позволяет отображать min/max/avg-значения метрики, а значений в каждой точке (timestamp) может быть одновременно несколько, то этим мы и воспользовались.


Изображение кликабельно, открывается в текущей вкладке веб-браузера.

Допустим, у нас есть достаточно редко изменяющаяся метрика (объем занятого места на диске), которую мы снимаем поминутно, а видеть хотим одно значение в час:

[12345,12345,…,12345] -> {min = 12345, avg = 12345, max = 12345} -> zabbix = [12345]
в этом случае нам достаточно всего одного значения в точке

Теперь возьмем загрузку CPU, которую снимаем посекундно, а видеть новые точки хотим лишь раз в 10 секунд:

[10,20,30,40,50,50,40,30,20,10] -> {min = 10, avg = 30, max = 50} -> zabbix = [10,30,50]
в этом случае нам достаточно всего 3 значений вместо 10 исходных

В чем же сложность?

Мы должны послать в Zabbix такой набор значений, что {min,max,avg}(zabbix) = {min,max,avg}(source). Если с min/max все просто и понятно, то «целевую» avg приходится иногда «подбирать» как решение уравнения:

(A * min + B * max + q) / (A + B + 1) = avg
где A,B – целые; min <= q <= max

Инициализируем массив результата:

[10,10,30,10,50,10,40,10,20,10] -> {min = 10, avg = 20, max = 50} -> zabbix = [10,50,…], -> .push(min)
-> zabbix = [10,50,10,…], -> .push(min)
-> zabbix = [10,50,10,10]
в этом случае нам понадобилось уже 4 значения, но все равно не 10

Таким образом, мы не пропустим сильное отклонение величины от среднего, раз можем повесить триггер на max или min, а график от avg визуально будет выглядеть так же, как если бы мы отправляли «сырые» данные.

Пока существующее решение уже позволяет нам значительно экономить дисковые ресурсы и снизить нагрузку на СХД и сам Zabbix, мы пытаемся придумать, как здесь можно применить какой-либо алгоритм потоковой аппроксимации. Если есть идеи – делитесь в комментариях.

Оптимизация отправки метрик

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

Чтобы уменьшить «непрофильную» нагрузку (открытие соединения, запуск парсера, …) при обработке принимаемых значений, мы группируем отсчеты в пакеты – по таймеру, чтобы не допустить сильного отставания от realtime, и по количеству (примерно по 1000), чтобы не «заткнуть» trapper-процесс обработкой надолго.

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

Благодаря использованию такой схемы, мы уже давно забыли, что такое nodata-«дыры» на графиках, вызванные перегрузкой Zabbix – ведь для этого должны оказаться заняты все трапперы.

Масштабирование и отказоустойчивость

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

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

Сейчас у нас работает всего 2 инстанса сбора с загрузкой около 25%.

«Сделай мне красиво!»

При использовании в качестве ядра NodeJS становится очень удобно разрабатывать эффективный фронтенд на «хипстерских» инструментах: React+Redux, ES6, Babel, Webpack, …

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

Ошибки мы не любим и поэтому сделали некоторые полезные фишки:

• массовые операции;
• клонирование хостов;
• автодополнение по мере ввода, где это возможно;
• различные фильтры;
• realtime-статусы;
• …

Изображение кликабельно, открывается в текущей вкладке веб-браузера.

Через админку пользователи добавляют и удаляют хосты и сервисы, выводят их на обслуживание (когда данные продолжают идти, а алерты отключаются). Сюда выводятся все ошибки мониторинга (неверные реквизиты доступа, невозможность «достучаться» до сервера, …). Здесь же есть аудитлог (аналогичный Zabbix’у), в который записываются все действия пользователей, что бывает полезно при разборах полётов.

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

Результаты

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

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

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

Забегая вперёд

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

Следите за новостями в нашем блоге. До скорых встреч!

Авторы: kilor (Кирилл Боровиков) и vadim_ipatov (Вадим Ипатов)

https://habrahabr.ru/post/329694/

https://habrahabr.ru/post/329718/

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

Ошибки на этапе проектирования и строительства

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

В проекте не предусмотрены целые системы. Некоторые считают, что ЦОД вполне может обойтись без системы гарантированного питания. т. е. ДГУ. Как-то один из заказчиков, для которого я делал аудит проекта дата-центра, спросил, какой будет уровень отказоустойчивости по Uptime без ДГУ. Я не нашел ничего лучшего, чем назвать Tier 0.
Многие воспринимают ДГУ как резерв, которым можно пренебречь при необходимости, – запасное же. В действительности относиться к нему стоит как к основному, потому что только этим видом энергоснабжения мы можем полностью управлять.

Единая точка отказа. Здесь возможны варианты:

• резервирования нет вообще. Тогда поломка или плановое обслуживание будет означать полную потерю элемента системы.
• резервирование выборочное. Этот вариант весьма условно можно назвать надежным, так как уровень резервирования системы все равно будет считаться по минимально зарезервированному элементу. Например, у вас продублированы лучи питания, ДГУ, распределительные щиты, PDU в стойке, а ИБП – нет. Если этот ИБП откажет, то все, что было в цепочке после него, уже не спасет.

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

• неправильная селективность. Селективность защищает от перегрузок и коротких замыканий. Для соблюдения селективности номинал автоматов от источника питания к потребителю должен уменьшаться. Если замкнет компрессор в кондиционере, то отключится автомат внутри кондиционера, а не тот, что стоит в распределительном щите.
• Если селективность не соблюдается, то автомат не выполнит своих защитных функций, и неисправность пойдет выше по цепи. Так из-за перегруза или короткого замыкания при неправильной селективности в машинном зале можно потерять целый луч питания.
• несоответствие сечения кабеля и мощности автомата. Если номинал автомата не соответствует сечению кабеля, то при превышении нагрузки автомат не выбьет, а вот кабель начнет перегреваться или – хуже – плавиться. Выбирайте автоматы и кабели в соответствии с таблицей для расчета сечения кабеля, тока и мощности.
• нет резерва по мощности. Проектирование внатяг – плохая практика. Оборудование стало потреблять больше, чем вы рассчитывали по проекту, понадобилось подключить дополнительное оборудование, потери на линии питания из-за длины трасс – все это можно пережить, если вы добавите 30% резерва к проектной мощности.
• не учтены пусковые токи. Оборудование, имеющее на борту электродвигатели, насосы или компрессоры, при запуске дает бОльшую нагрузку на сеть, чем в процессе работы. Если не предусмотреть этого в проекте, то вы не сможете одномоментно запустить несколько кондиционеров или чиллеров. Система не справится с нагрузкой, и автоматы отключатся.
• не учтены токи заряда аккумуляторных батарей (АКБ). ИБП отдает порядка 10% своей мощности на подзаряд АКБ. Если не учитываем эту дополнительную нагрузку, то ИБП не смогут перейти с питания от батарей на “город”: каждый раз, когда ИБП будет возвращаться на городское электроснабжение и начинать подзаряжать АКБ, автоматы будет выбивать.
• неправильная прокладка кабелей в гильзах между помещениями. Не совсем про расчеты, но тоже к строительству. Тут два момента:
  1. Все фазы (l1, l2, l3) нужно прокладывать в одной гильзе с нейтралью, иначе кабели начинают перегреваться.
  2. Когда используется несколько одножильных кабелей (за одну фазу используется несколько кабелей), проследите, чтобы кабели на лотках лежали в правильной последовательности (см. соответствующий раздел в ПУЭ). Не нужно их перекручивать, заплетать в косы для красоты, если не хотите, чтобы это все перегревалось.

Теперь по холодоснабжению:

• неправильная оценка уличных температурных условий. При проектировании часто берут за основу статистику по средней температуре в конкретном городе – без учета особенностей конкретного здания и из непроверенных источников. Если крыша здания сильно греется на солнце, то реальная температура будет на несколько градусов выше.
• плохая циркуляция воздуха между внешними блоками. Из-за плотного расположения и проблем со свободным проходом воздуха внешние блоки кондиционеров начинают засасывать отработанный горячий воздух друг друга. На улице может быть не так жарко, но температура на входе во внешний блок будет высокой. Такой же результат получите, если внешние блоки разместите рядом с выхлопной трубой ДГУ или над ДГУ, рядом с трансформаторами. Продумывайте, нет ли дополнительных источников тепла рядом с внешними блоками.
• неправильно рассчитанная реальная мощность кондиционеров и холодопроизводительность. Потребляемая мощность кондиционеров по паспорту не всегда соответствует действительности. Производитель показывает красивые цифры? Не поленитесь сами почитать документы и узнать, при каких условиях будут именно такие показатели. А какое потребление будет при максимальной нагрузке? Если в пиковую нагрузку кондиционеры начнут потреблять больше, чем заложено по проекту, то есть риск остаться без системы кондиционирования. Оставляйте резерв.
• Аналогично с холодопроизводительностью: в зависимости от длины трасс, уличной температуры и параметров работы она может меняться.

Ошибки в эксплуатации

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

Несбалансированная нагрузка по фазам и лучам. Мощность кабеля и автоматов используется эффективно, если нагрузка по фазам распределена равномерно. Когда одна или две фазы перегружены, а одна или две недогружены, возникает так называемый “перекос” фаз. Из-за него имеющаяся мощность используется нерационально. В худшем случае это приведет к отключению автомата и перегреву кабеля.
С лучами история следующая: в дата-центре с резервом энергоснабжения 2N при отключении одного из лучей питания второй берет на себя нагрузку вышедшего из строя. Чтобы оставшийся луч выдержал двойную нагрузку, каждый из них должен быть загружен только наполовину от номинальной мощности с учетом пусковых токов. В противном случае резерв по второму лучу не спасет.
Оба условия должны соблюдаться одновременно. Отследить распределение нагрузки от трансформаторов до PDU поможет мониторинг системы в максимальном количестве точек. Как это устроить, рассказывали в этой статье.

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

Инструкции и регламенты службы эксплуатации. В серверной или дата-центре предаварийное состояние, а инженер слабо понимает, что делать и кому звонить. Еще хуже, когда дежурный на посту решает ничего не делать. Регламенты и инструкции могут спасти от неразберихи и потери времени при ЧС.
Но регламент регламенту рознь: если он написан для галочки, никогда не актуализировался и никто не испытывал его во время учений, то можно считать, что регламента нет.
Даже если все схемы отработаны, регламенты и инструкции всегда должны быть под рукой (в бумажном и электронном виде), чтобы при аварии не приходилось тратить время на их поиски. Повесьте плакаты с краткими инструкциями на рабочем месте инженера, с которого начинается операция по спасению дата-центра в случае аварии. Инструкции по работе с оборудованием разместите прямо на корпусе оборудования. К инструкциям можно добавить чек-листы, в которых инженер будет отмечать каждое свое действие. Так будет меньше шансов пропустить пункты инструкции.

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

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

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

Что еще может привести к аварии

Посмотрим, что может пойти не так в работе кондиционирования, электроснабжения (система распределения питания, система бесперебойного питания, ДГУ) и системе пожаротушения.

Холодоснабжение. Для системы холодоснабжения все может начаться с поломки нескольких кондиционеров, например, из-за того, что внешние блоки забиты тополиным пухом. Если зал хорошо загружен и холода перестает хватать, то возникают локальные перегревы. Фреоновые кондиционеры очень чувствительны к температуре на входе, поэтому, когда она повышается, по ошибке начинают останавливаться и другие кондиционеры. В результате такого “эффекта домино” зал останется без охлаждения.

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

Бесперебойное энергоснабжение. Помимо выхода из строя ИБП, который можно предотвратить с помощью ТО и своевременного ремонта, есть такая интересная вещь, как несоответствие реального времени автономной работы ИБП и оценки на дисплее ИБП. Я, конечно же, о случае, когда дисплей показывает больше, чем на самом деле есть. Например, во время ТО щитов между ДГУ и ИБП, когда всю нагрузку держит АКБ, служба эксплуатации рассчитывает на одно время, а в реальности получает на пару минут меньше.
Избежать такого конфуза можно, если периодически проводить “контролируемый” разряд АКБ с построением соответствующих графиков. На основе этого графика рассчитывается время автономной работы и калибруются показания на экране ИБП. Для перестраховки полученное время лучше округлять в меньшую сторону. Тут как с часами: лучше пусть спешат и ты придешь на встречу раньше, чем опоздаешь.

Гарантированное энергоснабжение. Сбои могут произойти на любом этапе работы ДГУ:

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

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

На этом остановлюсь, хотя, конечно, это не все причины, из-за которых дата-центр может “прилечь”. Делитесь в комментариях своими историями. Если произошла авария, а причину так и не удалось выяснить, пишите здесь или на consulting@dtln.ru. Попробуем разобраться вместе.

Другие статьи по теме проектирования и эксплуатации дата-центров:
Мониторинг инженерной инфраструктуры в дата-центре. Часть 1. Основные моменты
Мониторинг инженерной инфраструктуры в дата-центре. Часть 2. Система энергоснабжения
Обслуживание инженерных систем ЦОД: что должно быть в договоре подряда
Ошибки в проекте дата-центра, которые вы ощутите только на этапе эксплуатации
Путь электричества в дата-центре
Как тестируют ДГУ в дата-центре
Опыт DataLine: как мы готовим дежурных инженеров для своих дата-центров
Опыт DataLine: работа службы техподдержки

https://habrahabr.ru/post/329744/

Название ENTRYPOINT всегда меня смущало. Это название подразумевает, что каждый контейнер должен иметь определенную инструкцию ENTRYPOINT. Но после прочтения официальной документации я понял, что это не соответствует действительности.

Факт 1: Требуется определить хотя бы одну инструкцию (ENTRYPOINT или CMD) (для запуска).

Если вы не определите ни одной из них, то получите сообщение об ошибке. Давайте попробуем запустить образ Alpine Linux, для которого не определены ни ENTRYPOINT, ни CMD.

$ docker run alpine
docker: Error response from daemon: No command specified.  
See 'docker run --help'.

Факт 2: Если во время выполнения определена только одна из инструкций, то и CMD и ENTRYPOINT будут иметь одинаковый эффект.

$ Cat Dockerfile 
FROM alpine  
ENTRYPOINT ls /usr  

$ Docker build -t test .

$ Docker run test
bin  
lib  
local  
sbin  
share  

Мы получим те же результаты, если будем использовать CMD вместо ENTRYPOINT.

$ cat Dockerfile 
FROM alpine  
CMD ls /usr  # Using CMD instead  

$ docker build -t test .

$ docker run test
bin  
lib  
local  
sbin  
share  

Хотя этот пример и показывает, что между ENTRYPOINT и CMD нет никакой разницы, её можно увидеть, сравнив метаданные контейнеров.

Например, первый файл Dockerfile (с определенной ENTRYPOINT):

$ docker inspect b52 | jq .[0].Config
{
  ...
  Cmd: null,
  ...
  Entrypoint: [
    /bin/sh,
    -c,
    ls /
  ],
  ...
}

Факт 3: И для CMD, и для ENTRYPOINT существуют режимы shell и exec.

Из руководства:

ENTRYPOINT имеет два режима выполнения:

• ENTRYPOINT ["executable", "param1", "param2"] (исполняемая форма, предпочтительно)
• ENTRYPOINT command param1 param2 (форма оболочки)

До сих пор мы использовали режим shell, или оболочки. Это означает, что наша команда ls -l запускается внутри /bin/sh -c. Давайте попробуем оба режима и изучим запущенные процессы.

Режим shell:

$ cat Dockerfile
FROM alpine  
ENTRYPOINT ping www.google.com  # shell format  

$ docker build -t test .

$ docker run -d test
11718250a9a24331fda9a782788ba315322fa879db311e7f8fbbd9905068f701  

Затем изучим процессы:

$ docker exec 117 ps
PID   USER     TIME   COMMAND  
    1 root       0:00 /bin/sh -c ping www.google.com
    7 root       0:00 ping www.google.com
    8 root       0:00 ps

Обратите внимание, что процесс sh -c имеет PID, равный 1. Теперь то же самое, используя режим exec:

$ cat Dockerfile
FROM alpine  
ENTRYPOINT [ping, www.google.com]  # exec format  

$ docker build -t test .

$ docker run -d test
1398bb37bb533f690402e47f84e43938897cbc69253ed86f0eadb6aee76db20d  

$ docker exec 139 ps
PID   USER     TIME   COMMAND  
    1 root       0:00 ping www.google.com
    7 root       0:00 ps

Мы видим, что при использовании режима exec команда ping www.google.com работает с идентификатором процесса PID, равным 1, а процесс sh -c отсутствует. Имейте в виду, что приведенный выше пример работает точно так же, если использовать CMD вместо ENTRYPOINT.

Факт 4: Режим exec является рекомендуемым.

Это связано с тем, что контейнеры задуманы так, чтобы содержать один процесс. Например, отправленные в контейнер сигналы перенаправляются процессу, запущенному внутри контейнера с идентификатором PID, равным 1. Очень познавательный опыт: чтобы проверить факт перенаправления, полезно запустить контейнер ping и попытаться нажать ctrl + c для остановки контейнера.

Контейнер, определенный с помощью режима exec, успешно завершает работу:

$ cat Dockerfile 
FROM alpine  
ENTRYPOINT [ping, www.google.com]  

$ docker build -t test .

$ docker run test
PING www.google.com (172.217.7.164): 56 data bytes  
64 bytes from 172.217.7.164: seq=0 ttl=37 time=0.246 ms  
64 bytes from 172.217.7.164: seq=1 ttl=37 time=0.467 ms  
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss  
round-trip min/avg/max = 0.246/0.344/0.467 ms  
$

При использовании режима shell контейнер работает не так, как ожидалось.

$ cat Dockerfile 
FROM alpine  
ENTRYPOINT ping www.google.com  

$ docker build -t test .

$ docker run test
PING www.google.com (172.217.7.164): 56 data bytes  
64 bytes from 172.217.7.164: seq=0 ttl=37 time=0.124 ms  
^C^C^C^C64 bytes from 172.217.7.164: seq=4 ttl=37 time=0.334 ms
64 bytes from 172.217.7.164: seq=5 ttl=37 time=0.400 ms  

Помогите, я не могу выйти! Сигнал SIGINT, который был направлен процессу sh, не будет перенаправлен в подпроцесс ping, и оболочка не завершит работу. Если по какой-то причине вы действительно хотите использовать режим shell, выходом из ситуации будет использовать exec для замены процесса оболочки процессом ping.

$ cat Dockerfile
FROM alpine  
ENTRYPOINT exec ping www.google.com  

Факт 5: Нет оболочки? Нет переменных окружения.

Проблема запуска НЕ в режиме оболочки заключается в том, что вы не можете воспользоваться преимуществами переменных среды (таких как $PATH) и прочими возможностями, которые предоставляет использование оболочки. В приведенном ниже файле Dockerfile присутствуют две проблемы:

$ cat Dockerfile 
FROM openjdk:8-jdk-alpine  
WORKDIR /data  
COPY *.jar /data  
CMD [java*, *-jar*, **.jar*]  # exec format  

Первая проблема: поскольку вы не можете воспользоваться переменной среды $PATH, нужно указать точное расположение исполняемого java-файла. Вторая проблема: символы подстановки интерпретируются самой оболочкой, поэтому строка *.jar не будет корректно обработана. После исправления этих проблем итоговый файл Dockerfile выглядит следующим образом:

FROM openjdk:8-jdk-alpine
WORKDIR /data
COPY .jar /data
CMD [/usr/bin/java, -jar, spring.jar*]

Факт 6: Аргументы CMD присоединяются к концу инструкции ENTRYPOINT… иногда.

Вот тут-то и начинается путаница. В руководстве есть таблица, цель которой – внести ясность в этот вопрос.

Попытаюсь объяснить на пальцах.

Факт 6a: Если вы используете режим shell для ENTRYPOINT, CMD игнорируется.

$ cat Dockerfile 
FROM alpine  
ENTRYPOINT ls /usr  
CMD blah blah blah blah  

$ docker build -t test .

$ docker run test
bin  
lib  
local  
sbin  
share  

Строка blah blah blah blah была проигнорирована.

FACT 6b: При использовании режима exec для ENTRYPOINT аргументы CMD добавляются в конце.

$ cat Dockerfile
FROM alpine  
ENTRYPOINT [ls*, */usr*]  
CMD [/var*]  

$ docker build -t test .

$ docker run test
/usr:
bin  
lib  
local  
sbin  
share

/var:
cache  
empty  
lib  
local  
lock  
log  
opt  
run  
spool  
tmp  

Аргумент /var был добавлен к нашей инструкции ENTRYPOINT, что позволило эффективно запустить команду ls/usr/var.

Факт 6c: При использовании режима exec для инструкции ENTRYPOINT необходимо использовать режим exec и для инструкции CMD. Если этого не сделать, Docker попытается добавить sh -c в уже добавленные аргументы, что может привести к некоторым непредсказуемым результатам.

Факт 7: Инструкции ENTRYPOINT и CMD могут быть переопределены с помощью флагов командной строки.

Флаг --entrypoint может быть использован, чтобы переопределить инструкцию ENTRYPOINT:

docker run --entrypoint [my_entrypoint] test  

Все, что следует после названия образа в команде docker run, переопределяет инструкцию CMD:

docker run test [command 1] [arg1] [arg2]  

Все вышеперечисленные факты справедливы, но имейте в виду, что разработчики имеют возможность переопределять флаги в команде docker run. Из этого следует, что ...

Достаточно фактов… Что же делать мне?

Ok, если вы дочитали статью до этого места, то вот информация, в каких случаях использовать ENTRYPOINT, а в каких CMD.

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

Используйте ENTRYPOINT, если вы не хотите, чтобы разработчики изменяли исполняемый файл, который запускается при запуске контейнера. Вы можете представлять, что ваш контейнер – исполняемая оболочка. Хорошей стратегией будет определить стабильную комбинацию параметров и исполняемого файла как ENTRYPOINT. Для нее вы можете (не обязательно) указать аргументы CMD по умолчанию, доступные другим разработчикам для переопределения.

$ cat Dockerfile
FROM alpine  
ENTRYPOINT [ping]  
CMD [www.google.com]  

$ docker build -t test .

Запуск с параметрами по умолчанию:

$ docker run test
PING www.google.com (172.217.7.164): 56 data bytes  
64 bytes from 172.217.7.164: seq=0 ttl=37 time=0.306 ms

Переопределение CMD собственными параметрами:

$ docker run test www.yahoo.com
PING www.yahoo.com (98.139.183.24): 56 data bytes  
64 bytes from 98.139.183.24: seq=0 ttl=37 time=0.590 ms  

Используйте только CMD (без определения ENTRYPOINT), если требуется, чтобы разработчики могли легко переопределять исполняемый файл. Если точка входа определена, исполняемый файл все равно можно переопределить, используя флаг --entrypoint. Но для разработчиков будет гораздо удобнее добавлять желаемую команду в конце строки docker run.

$ cat Dockerfile
FROM alpine  
CMD [ping*, *www.google.com*]  

$ docker build -t test .

Ping – это хорошо, но давайте попробуем запустить контейнер с оболочкой вместо команды ping.

$ docker run -it test sh
/ # ps
PID   USER     TIME   COMMAND  
    1 root       0:00 sh
    7 root       0:00 ps
/ # 

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

Очистка

После запуска команд на хосте осталась куча остановленных контейнеров. Очистите их следующей командой:

$ docker system prune

Обратная связь

Буду рад услышать ваши мысли об этой статье ниже в комментариях. Кроме того, если вам известен более простой способ поиска в выдаче докера с помощью jq, чтобы можно было сделать что-то вроде docker inspect [id] | jq * .config, тоже напишите в комментариях.

Джон Закконе

Капитан Докера и инженер по облачным технологиям в IBM. Специализируется на Agile, микросервисах, контейнерах, автоматизации, REST, DevOps.

Ссылки:

1. ENTRYPOINT vs CMD: Back to Basics

https://habrahabr.ru/post/329138/

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

За последний год Intel добавила аппаратную поддержку ЦПУ в нескольких фреймворков глубокого изучения для оптимизации приложений, делающих выводы на основе анализа. Основой этих оптимизаций является Intel Math Kernel Library (Intel MKL), использующая инструкции Intel Advanced Vector Extension (Intel AVX-512) для расширенной поддержки функционала глубокого изучения.

Caffe2 — это open source фреймворк глубокого изучения, созданный Facebook и отличающийся высокой скоростью работы и модульным исполнением. Caffe2 разработан для того, чтобы помочь исследователям тренировать большие модели машинного обучения и разрабатывать AI для мобильных устройств.

Intel и Facebook совместно интегрируют функции Intel MKL в Caffe2 для оптимальной производительности получения выводов. Таблица ниже показывает скорость получения выводов с
использованием библиотек Intel MKL и Eigen BLAS. В таблице OMP_NUM_THREADS показывает количество используемых физических ядер. Результаты показывают, что Caffe2 может быть хорошо оптимизирован с точки зрения процессора. Для небольших пакетов нагрузок рекомендуется использовать свое процессорное ядро для каждой нагрузки и запускать их параллельно.

	OMP_NUM_THREADS=44		OMP_NUM_THREADS=1
Размер пакета	Intel MKL (изобр./сек)	Eigen BLAS (изобр./сек)	Intel MKL (изобр./сек)	Eigen BLAS (изобр./сек)
1	173.4	5.2	28.6	5.1
32	1500.2	29.3	64.6	15.4
64	1596.3	35.3	66.0	15.5
256	1735.2	44.9	67.3	16.2

Ранее в этом году на рынок были выведено новое поколение процессоров Intel Xeon (кодовое название Skylake). Одной из новинок Skylake стали 512-битные инструкции Fused Multiply Add (FMA) как часть векторного набора Intel AVX-512, обеспечивающего существенный прирост производительности по сравнению с предыдущими 256-битными инструкциями AVX2 как для тренировки моделей, так и для подсчета выводов. 512-битные функции FMA вдвое увеличивают достигаемые процессором FLOPS и сильно ускоряют матричную арифметику одинарной точности, используемую в сверточных и рекурентных нейронных сетях. Подсчет выводов хорошо параллелизуется и получит выгоду от увеличения количества ядер в новых процессорах. Кроме того, на скорости работы благотворно скажется увеличение частоты памяти и размера кэша Mid-Level-Cache (MLC) на одно ядро.

https://habrahabr.ru/post/329682/

На прошлой неделе состоялась конференция Positive Hack Days 7, в рамках которого прошла теперь уже можно сказать традиционная (второй раз, чем не традиция?) битва Защитников и Атакующих — Противостояние (The Standoff).

Суть такова… Участник может играть SOCами, охраной города и злодеем. И если пользователь играет защитниками то ему дают разные средства защиты, а на сегменты города набигают злодеи. Можно грабить корованы…

Участники Противостояния

Более подробное описание ролей участников есть на сайте организатора (Positive Technologies):

Подготовка

Первый общий брифинг участников Противостояния состоялся 12 апреля, где организаторы рассказали о планах построить город, который надо будет «хачить» и защищать. Нам досталась роль SOC на одном из офисных сегментов. Защитниками этого сегмента стала команда S.P.A.N (Servionica Palo Alto Networks).



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

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



Офисный сегмент города организаторы полностью подняли в виртуальной инфраструктуре на базе VMware.

Примерно за три недели до начала мероприятия мы получили доступ (спасибо организаторам) к виртуальной машине с MaxPatrol 8 для сканирования и построения карты сети. Получилось 1719 страниц pdf-отчёта.

Неделю мы устанавливали и тестировали наши средства мониторинга. Мы планировали использовать:

• IDS для Офиса.
• IDS для Города.
• Moloch для записи и анализа трафика.
• Network Analyzer для выявления аномалий в трафике Офиса.
• Network Analyzer для выявления аномалий в трафике Города.
• HIDS (host IDS) для контроля ключевых серверов Офиса.
• TIAS для анализа логов, мониторинга и аналитики.

Всё работало как надо. Мы расписали смены дежурств группы мониторинга.

Пентестер заявил, что «на площадке буду все 30 часов и отлично оторвусь».

Пиарщик сказал, что «PHDays — это единственная возможность сделать угарный баннер».



Было ощущение, что мы готовы.

Началось!

На самом деле нет.

«Парни, на наших сенсорах нет трафика!» — это наш девиз и призыв к организаторам на первые 8 часов Противостояния, которое началось примерно в 11-30.

К сожалению, из-за технических трудностей, только к 19 часам удалось подать трафик на обе IDS:

• На Офисную был подан только трафик из DMZ, хотя требовалось зеркало всего трафика.
• На Городскую был подан трафик внешнего периметра Офиса и трафик ещё нескольких vlan’ов без конкретизации.

По объёму и наблюдаемым событиям было понятно, что зеркалируется далеко не весь трафик (хотя запросили по максимуму). Про зеркало трафика на Moloch и говорить не стоит. А без него и анализ аномалий смысла не имеет.

Фактически, всё, что мы делали на неделе перед мероприятием, пришлось переделывать заново прямо на площадке. Тем не менее, всё-таки надо поблагодарить и админов организаторов, они впрягались и помогали, где могли.

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

Прямой доступ в контролируемую инфраструктуру отсутствовал, все лезли через VPN, что также не добавляло радости. Грусть печаль тоска… Но грустное на этом заканчивается!

1. Не стоит забывать, что Атакующие находились в тех же условиях, а для них ведь важен простор, свобода — сидели они периодически гораздо более грустные, чем защитники.
2. Трафик хоть какой-то получен — значит уже можно работать!
3. Защитники к взаимодействию открыты, бреши перекрывают — значит всё не так уж плохо на сегодняшний день.

Ещё одна интересная история была с динамическим распределением ресурсов на ферме виртуализации. Два аналитика SOC сидели рядом. Их рабочие места тоже в виртуалках. У одного всё летало, а другой тихо матерился в монитор и говорил, что никогда не видел, чтобы консоль тормозила.



В итоге за ночь и ещё почти целый день мониторинга мы успели и атаки навыявлять, и контролируемый сегмент поисследовать.

Что зафиксировали

По офисному сегменту

1. Как только дали трафик, с адреса 198.18.78.12 постоянно кто-то ломился на один из наших web-серверов (198.18.12.177) с непонятными и всегда одинаковыми кредами. Проверили — активность странная, но не опасная. Потом ещё всю ночь будем об этом думать. Чего хотели — остаётся загадкой. Видимо, у Атакующих что-то пошло не так.
2. На фоне п.1. с того же адреса постоянно шли сканы, валились эксплоиты и прочая нечистая сила. Идентифицировали NAT Атакующих. Жаль блочить было нельзя – fair-play и всё такое.
3. Подозрение на компрометацию нашего сервера (198.18.12.169) из DMZ — с него шёл нездоровый интерес к mysql внутреннего ресурса (10.25.153.24). Защитники не отвечали, сколько не спрашивали. Ничего другого от данного адреса видно не было. Компрометация не подтвердилась, возможно системный чекер. Следили за ним одним глазом.
4. Пока мониторили, параллельно исследовали свой же DMZ. На еще одном web-cервере (198.18.12.179) обнаружена XSS. Мы до обеда следующего дня маячили об этом защитникам. Как только начали массово пытаться внедрить xss, они быстро отреагировали и запретили спецсимволы в url. Как никто из атакеров не воспользовался — загадка!
5. На том же web-сервере (198.18.12.179) зафиксировали pureFTP. СЗИ блочили чуждые обращения к FTP. Всё в порядке.
6. На третьем web-сервере (198.18.12.180) нашли открытый репозиторий сайта (/.git) и оповестили защитников. Они оперативно закрыли. Командная работа!
7. Около 00:30 во внутренней сети активизировалась подсеть 10.64.94.0/24. Оттуда сразу начался брутфорс сервисов в DMZ. Защитники блокировали данную подсеть, другого выхода не было. *Да-да блочить нельзя, но врага внутри оставлять тем более нельзя — поломают всё!
8. Ещё один web-сервер (198.18.12.141), ещё одна доступная директория /install. Атакующие могли перетянуть сайт на свою базу данных и скомпрометировать пользователей. Защитники закрыли к папке доступ.
9. Среди ночи началась аномальная активность между пользовательским сегментом и контроллером домена! Атаковали SMB. Разбор показал, что СЗИ от НСД Secret Net живёт своей жизнью и пытается общаться с главным сервером. Ок, false positive — поехали дальше.
10. На 198.18.12.169 обнаружили /wp_include со всеми исходниками. Защитники закрыли.
11. С 05:00 до 07:00 затишье. Покемарили.
12. С 8:00 начали сканить с новыми силами, уже не пытаясь скрыться и не стесняясь в средствах: nmap, sqlmap, nessus, куча самописных сканеров (ну или просто скрипты к nmap’у). Особенно порадовал сканер, судя по user-agent: go-http-client — самописный, прошёлся по приличному набору уязвимостей.
13. Кругом бардак — эксплойты, инъекции, брутфорсы, сканы. Всего много, но всё одинаковое, бесполезное и неинтересное.
14. Увидели, что появился узел 198.18.12.143. На нём был wordpress (почти как везде) с открытым API-доступом с кредами admin:admin123. Подобрали вручную со второй попытки. Заалертили, оперативно закрыли.
15. До последнего брутили доступ к FTP. Коннекты рубились СЗИ.

Из фейсбука члена команды S.P.A.N.

— Я безопасник, я не хочу ничего решать, я хочу писать кастомные сигнатуры и смотреть, как дропаются пакеты.

— О, пошли дропы!

По городу

1. 20:26 зафиксировали успешный брутфорс smb 172.20.3.147 от 10.25.21.23. Чей адрес — неизвестно. Не повезло кому-то.
2. Вообще, по городу кругом торчали smb, snmp, sql. Атакующие гуляли по ним, как по своим. Брутфорс по всем фронтам.
3. Зафиксировали, что на узле 203.0.113.169 (вроде объект Телеком) wordpress и открыта админка… Были бы не white hat, сами бы сломали.
4. Под конец повторно успешно сбрутили smb 172.20.3.147 от 10.25.21.24 (возможно те же самые, просто не выключили скрипт).

Что получилось и не получилось

Если оценивать глобально — атакующие молодцы! И АСУ ТП поломали, и банк обчистили, и вроде даже смски «мэра» перехватили. Что касается нашего Офиса — остался нетронут, и команда защитников завершила Противостояние с полными 100% «репутации».

Конечно, от атакующих мы ожидали более сильного напора. С чем были связаны их сложности? У нас есть три гипотезы:

1. Они не использовали весь свой арсенал. Противостояние — это всё-таки игра и, возможно, нам не показали все инструменты, чтобы иметь запас на реальные проекты. А широко известные инструменты и техники легко блочились средствами защиты.
2. У атакующих (как и у защитников) не было прямого доступа к сети Города, возможно, часть арсенала просто не взлетела.
3. У атакующих появляются сложности, когда им оказывают активное и оперативное противодействие. Если действовать в лоб — это видно, а если тоньше — то и времени уйдёт больше, и требования к скиллу уже другие.

Очень печально, что были такие масштабные технические трудности, трафика было мало. А ведь это шикарное всё-таки пространство для аналитики!

К следующему году учтём все ошибки и будем понимать, что требовать от организаторов. Ждём PHDays 8.

Благодарности

Благодарим Positive Technologies (особо — Викторию, Алексея, Михаила и Тамару) за организацию этого праздника.

Благодарим команду S.P.A.N. за защиту, опыт и хорошую командную игру.

Спасибо всей нашей команде, вы очень крутые.

И отдельное спасибо капитану команды мониторинга Максиму Baymaxx за подготовку этого отчёта.



Теперь табличка со «Всевидящим оком» украшает одну из стен Центра мониторинга.

Другие статьи блога

UAC Bypass или история о трех эскалациях

Отчёт Центра мониторинга информационной безопасности за I квартал 2017 года

Жизнь без SDL. Зима 2017

https://habrahabr.ru/post/329730/

https://habrahabr.ru/post/329740/

https://habrahabr.ru/post/329738/

Началось всё, видимо, как обычно, — с Большого взрыва, может, чуть позже. Когда электронов вокруг ядра стало 14. Или в первый день сотворения мира, а именно создания неба и земли (но именно в тот момент, когда электронов стало 14). Или же на второй день полёта по миру макаронного монстра (ну про 14 электронов вы поняли). А может быть, когда появился тот самый единственный электрон, который сразу везде и нигде (но, как минимум, четырнадцать раз вокруг одного ядра). В тот момент в мире появился кремний. Который сначала в XIX веке именовался силицием, затем в России обрёл крепкое древнегреческое прозвище (в переводе на русский “кремний” — утёс, гора). А через век стал основой для полупроводниковых микросхем и силикона и дал жизнь двум долинам в Калифорнии. Одной — чисто силиконовой (silicon), в России именуемой для дифференциации Кремниевой. Другой — порно-силиконовой (silicone), да и хватит с неё, и так много чести быть опять упомянутой рядом.

В середине XX века за счёт научно-технического прогресса, дальновидности руководства Стэнфордского университета, наличия собственной земли и завещания Лелана Стэнфорда, а также некоторых других факторов, Кремниевая долина близ города Сан-Франциско (Пало-Альто) стала флагманом технического развития в мире. Теперь в каждом государстве, если создают какой-нибудь технопарк, то сразу гордо нарекают его второй кремниевой долиной. Поэтому к XXI веку вторых кремниевых долин насчитывается уже около сотни. Последняя из них, с подачи Дмитрия Анатольевича Медведева тоже Кремниевая, родилась в 2015-м году под Казанью.


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

Кремниевые острова. Япония

В 1970-х годах на японском острове Кюсю многие компании начали открывать предприятия по производству кремниевых полупроводниковых устройств. С тех пор на острове главной отраслью производства считается электроника, с тех пор остров и именуется кремниевым. Экономическую основу составляют префектуры Фукуока, Нагасаки и Кумамото. Среди известных компаний острова — Mitsui, Mitsubishi, Toshiba, Sony, Kuyshu Electric, и так или иначе все известные японские бренды. Впрочем, полноценно считать Кюсю аналогом кремниевой долины нельзя. В промышленном отношении всё это так. Но деловым центром Японии является Токио, и в отличие от того же Гугла, мозговые центры большинства технологических компаний Кюсю находятся вне острова, поэтому самостоятельности, идеологии и какой-то самобытности Кюсю лишён.

Тайвань

Примерно одновременно с Кюсю начинает развиваться рядом лежащий Тайвань. Несмотря на военное положение, длившееся полвека, конфликт с материковым Китаем, остров за это время смог стать одним из “Четырёх азиатских тигров”, куда также входят Южная Корея, Гонконг и Сингапур. Прогресс Тайваня выглядит впечатляюще. До 70-х годов на острове развивались только сельское хозяйство, текстиль и другие дешёвые производства. К 70-м бурно росла пиратская деятельность, где только можно, например, в производстве дорогостоящих учебников по разным дисциплинам. К 80-м учебники и остальное стали лицензионными. А к 90-м Тайвань уже вовсю производил компьютерное оборудование. Очень серьёзное влияние оказала на остров японская культура, ведь до Второй мировой войны Тайвань долгое время был японским.

Сингапур

Источник: koreaittimes.com

Без участия Японии на Сингапуре тоже не обошлось. Правда оно было очень недолгим, но зато каким эффектным! Во время Второй мировой войны англичане проиграли битву за Сингапур, поскольку ожидали нападения японцев с моря, а те, будучи морской державой, прошли к острову по суше. Видимо, руководство Сингапура, в первую очередь, легендарного Ли Куан Ю, это очень удивило и вдохновило, и экономический прорыв в послевоенные десятилетия для всех стал тоже неожиданным. Ли Куан Ю сумел придать острову инвестиционную привлекательность, снизив коррупцию до нуля и чуть ли не лично помогая наладить производство каждой транснациональной корпорации (ТНК) на территории. Как итог, Сингапур — высокотехнологичный город, лидер производств всего во всём. Крупный инвестиционный центр. Экономическое чудо XX века. Ещё один кремниевый остров.

Ирландия

Если гиганты настоящей кремниевой долины выбирают территорию твоей однокомнатной квартиры для организации производства, ты становишься кремниевым филиалом. Со стороны тебя, конечно, будут величать очередной второй долиной, ты получишь мощный заряд от инвестиционных рек, но ничего самостоятельного в этом подвиге нет, разве только то, что ты сумел привлечь внимание к своей однушке. Но так случилось только потому, что тебя выбрали. Ты избран, Нео, избран ТНК стать очередным филиалом в матрице. С Ирландией прошёл тот же фокус, но не совсем. Правительство (ещё при Маргарет Тэтчер) последовательно снижало налог на корпоративную прибыль, доведя в итоге до самого низкого в Европе (12,5%), добившись интереса со стороны корпораций США. Странно, конечно, что те же французы, например, со ставкой 30% не видят экономической целесообразности в снижении налога (в казне Ирландии доля дохода от таких налогов составляет 15%, во Франции — всего 5%). Но мало того, что “кельтскому тигру” удалось стать “кремниевым островом”, эти инвестиции он ещё и использовал крайне выгодно, направив доходы на всяческую поддержку местных IT-разработчиков. Поэтому Ирландия сейчас занимает первое место в Европе по разработке ПО. Секретов успеха ирисковых IT-компаний два:

1. Они доделывают за крупными игроками те решения, до которых у последних не доходят руки. Выходит интересный симбиоз. И гиганты не против такого усовершенствования их продукта, и ирландские стартапы получают гарантированный приток клиентов.
2. Ирландцы не хотят большого успеха. “Нам удобно быть маленькими — проще быть гибкими, открытыми для клиентов, проще их понять и предложить то, что им действительно нужно”, — говорят они. При этом никакой конкуренции, каждый занят своей нишей, ещё добавить хорошие льготы для малого и среднего бизнеса — замечательно живётся ирландским разработчикам.

Дания-Швеция

Источник: mediconvalley.com
Медиконовая долина географически и не долина вовсе, а датский остров Зеландия и пригород шведского Мальмё на Скандинавском полуострове, разделённые Зундским проливом. В 1983 году был образован научный парк IDEON, к которому позже добавились ещё шесть подобных. Парки специализируется на биомедицинских технологиях. Всего в долине насчитывается порядка 300 компаний, среди которых датский медицинский гигант Novo Nordisk — главный налогоплательщик королевства, публичная фармацевтическая компания Genmab, более известная в России LEO Pharma и ещё что-то шведское (менее известно, в конце поймёте, почему). Максимум в компаниях насчитывается до 50 человек, поэтому они легко управляемые. Всего в долине проживает более 3 млн. человек, из них 40 тыс. — научных работников, 150 тыс. студентов (обучающихся в 14 медиконовых университетах). Долина является регулярным поставщиком нобелевских лауреатов. Но главная особенность, за которую долину называют неофициальным государством, — это идеология персональной медицины. С 1998 г. каждый сотрудник долины стремится к тому, чтобы к любому пациенту найти свой индивидуальный подход, поскольку согласно исследованиям, в 30% случаях универсальные рецепты против таких болезней, как рак и диабет, не работают.
Забавный факт. Дания своим более лояльным трудовым и налоговым законодательством тянет одеяло на себя. Выходит так, что шведская часть населения долины по утрам выезжает на работу в Данию, а вечером возвращается к себе домой. Такое шведское Подмосковье. И скорее всего, это является причиной преобладания датских брендов в долине — в Швеции удобно жить, а не работать

Индия

Однажды в XII веке очередной индийский правитель заблудился в лесу, наткнулся на деревню и заночевал там. Женщина, у которой он остановился, из почтения накормила его самым дорогим, что у неё было — варёными бобами. Правитель из уважения назвал это место — “деревней варёных бобов” — Бенгалуру (но вполне возможно, всё было не так и ещё раньше).
Однажды в 1985 г. Texas Instruments стал первой ТНК, расположившейся в Бангалоре. Но за этим ничего не последовало, и к кремниевому Бангалору Техас причастен разве что своим первопроходчеством, возможно, в той же степени, в какой и варёные бобы связаны с названием города.
IT-компании пошли сюда как раз в разгар кризиса доткомов 2001 года. Видимо, этому способствовала дешёвая рабочая сила и некоторая англоязычность населения, ну и тот же Техас (к слову, соперник Пало-Альто со своими кремниевыми холмами в Остине). За год их количество увеличилось почти с нуля до трёх сотен, среди которых научные центры Sun Microsystems, Intel, Cisco, исследовательские центры Google, Microsoft, и многие другие. И это несмотря на отсутствие в городе стабильного электричества, дорог и аэропорта. Сейчас Бангалор — полноценный кремниевый филиал. В IT-районах жизнь вполне приличная и европейская, за их границами сразу же начинаются трущобы, мусор и голод. Типичный город контрастов, в отличие от Дублина или Сингапура.

Китай

Кремниевый научный городок Чжунгуаньцунь располагается в одном из самых густонаселённых районов Пекина — Хайдянь (3 200 000 человек на 2010 г.). В 1980 году из более чем миллиарда китайцев нашёлся один — Чэнь Чуньсянь — пошедший против и вперёд системы. Он открыл тогда ещё на улочке Чжунгуаньцунь (ну как “улочке” — в Сибирь бы такую “улочку”) первое (!) частное инновационное предприятие “Служба поддержки передовых технологий”. Несмотря на то, что вектор политики Китая только-только сменился с тоталитарного “особого пути” на социалистическую рыночную экономику, Чуньсяня нещадно критиковали (старое недоброе “куда ты лезешь, тебе что — больше всех надо — сиди и не высовывайся” распространено не только в России). Однако взявший новый курс ЦК компартии инициативу поддержал. Тут же начался целый шквал заявок, и к 1986 году в одном только Чжунгуаньцуне существовало 100 частных инновационных предприятий.
Тогда и был построен технопарк, получивший одноимённое с улицей название. В 2007 году в нём насчитывалось более 22 тысяч высокотехнологичных предприятий, в которых работало около миллиона человек, приносивших более $200 миллиардов совокупного дохода. В настоящее время в Чжунгуаньцуне имеют филиалы:
— 43 из 500 крупнейших компаний мира;
— 4 из 10 компаний-производителей ПО;
— 23 транснациональные корпорации;
— 20 китайских компаний-участников списка NASDAQ (Baidu, Sohu, Sina и др.).
Причём общая доля местных фирм составляет более 59% (113 фирм). И их вклад в высокотехнологичное развитие соизмерим с мировым (в первую очередь, компании “Фондер” и “Легенд”).
В технопарке Чжунгуаньцунь имеются секторы со всеми отраслями: энергетика и окружающая среда, инновационные материалы, цифровые технологии, аэрокосмическая промышленность, биомедицина. Есть и так называемая стартап-деревня Innoway, состоящая из целого ряда (некоторые обоснованно считают — пузыря) инкубаторов, продвигающих стартапы.

Большая (маленькая) пятёрка

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

Источник: twizz.ru. Европятёрка — британец слева, Испания-Италия на спинах

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

София-Антиполис (Антиб-Вальбонн, Франция) — технопарк образован в 1970-1984 гг. София — супруга основателя парка сенатора Лафита. Имеется ряд высших учебных заведений, штаб-квартира консорциума Всемирной паутины W3C, а также более 40 компаний.

Саксонская кремниевая долина (Дрезден, Германия) — всё то же самое, только дисциплина и немцы.

Технопарки Коста-дель-Сол (Малага, Испания) и Катании (Италия) — то же, что в Германии, только тепло и туризм в виде конкурирующей (и как следствие, расслабляющей даже научных сотрудников) сферы деятельности.

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

А что с Иннополисом? Взгляд со стороны

Источник: izent.ru
Об уровне заинтересованности государства, которое и стало инициатором Иннополиса, может служить следующий факт. На строительство целого города было потрачено 26 млрд. рублей. Злосчастная и бездонная футбольная Зенит-арена.до сегодняшнего дня накопила уже 50 млрд.рублей расходов. Расходы на науку в России, как минимум, в 3 раза меньше, чем на оборону (1 против 3 трлн. рублей соответственно). С США и Китаем сравнивать стыдно (там обе категории исчисляются сотнями миллиардов долларов). Но тем не менее Иннополис жив, и кажется, будет жить. Да и создавало государство Иннополис для it-бизнеса, в первую очередь, — мол, “условия созданы, а дальше вы уж сами”.
А созданы ли? Вот несколько фактов.

1. Специалистов, читай, жителей в городе откровенно не хватает. Для них город запустил бесплатную программу специализированной подготовки с дальнейшим трудоустройством в компании-резиденты. Да вот беда — таких компаний в городе фактически тоже нет. Разве только Сбертех — главный партнёр проекта IT-города. В настоящее время в Сбертехе Иннополиса числится чуть более 180 сотрудников. В планах довести их до 500. Про планы отдельно. Здесь же выходит: из заявленных 150 тысяч жителей за 2 года еле набирается 2 тысячи (официально зарегистрированных — чуть более 100 плюс 700 имеющихся и уже занятых квартир плюс студенты и приезжие сотрудники из соседних мест — в основном, Казани). Кстати, вот полугодовые итоги программы — подано 9000 заявок, отобрано 140 кандидатов, из них 85% получили работу. Маловато. И всё из-за отсутствия спроса в городе.
2. IT-компании в город не тянутся — это видно. Кажется, как будто присматриваются к новому явлению. Из резидентов сейчас числятся 40 компаний. Но это прописью, фактическое количество могут сообщить только обитатели Хабра и Иннополиса одновременно. Среди сорока указан и главный интернет-гигант России — Яндекс. Об открытии офиса Яндекс сообщил ещё в июне 2016 г. Однако через два месяца офис открыт так и не был. Обещанных всем IT-компаниям налоговых льгот Яндекс не получил, но из уважения сообщил, что доволен даже скидкой на аренду помещения. Об офисе до сих пор официально ничего не известно. Его нет на карте, его нет в списке офисов на соответствующей странице. Кто видел офис Яндекса в Иннополисе, сообщите, пожалуйста. Но логично скорее его отсутствие, поскольку: налоговых льгот нет, рядом офис в Казани и там пока всё сыро. Зачем идти Яндексу в Иннополис? Пока незачем.
3. Первый мэр Иннополиса Егор Иванов спустя два года ушёл в отставку. Не от хорошей жизни наверняка. Мотивировал он своё решение просто — возвращается домой, в Москву. Никаких причин и намёков.
4. За последние несколько месяцев Иннополис балует новостями только местные татарстанские издания. Впрочем, среди них числятся и крупные события: и приобретение группой Qiwi резидента Иннополиса, и планируемые инвестиции Тинькофф банка, и вложение китайского инвестора в российского конкурента Android. Так или иначе все новости — это заверения в счастливом будущем. В России заверять умеют, как и штамповать многочисленные отчёты об успешном и светлом прошлом. К слову, о светлом прошлом — компания Иннополис и университет Иннополис недавно прекратили вести блоги на Хабре. Видимо, смущают цены (и опять же, к слову, цены действительно дикие, доступные лишь избранным компаниям). Единственные ресурсы, где Иннополис стабильно активен — это социальные сети (но это развлекуха, в основном).
5. Из уже свершившихся достижений Иннополиса — это автобусы на электродвигателях, дроны в ЗАГСе, подносящие кольца брачующимся, многочисленные роботы, играющие в футбол, и гордость, чаще всего упоминаемая в сети, — телеграм-боты и консьерж-сервис. Большинство касается инфраструктуры или образования, но опять же не бизнеса.
6. За образование, пожалуй, можно поставить твёрдый плюс. Судя по отзывам студентов и преподавателей, эта сфера реально сейчас развивается. Студенты восторженно отзываются на всех ресурсах и погружены в учебный процесс 16 часов в день. И именно студенты и преподаватели вселяют надежду, что всё действительно будет хорошо.

Как выразился один из IT-специалистов, “Иннополис — это лучшее, что случалось с образованием и наукой в России за последние 25 лет”. Два года для IT-града — действительно малый срок. Ещё даже не было первого университетского выпуска. Кто знает, может, несколько из этих студентов с горящими глазами рванут так, что никакая затхлость и коррупция за ними не поспеет? И вытянут Иннополис в кремниевое будущее, как это сделали в своё время ирландцы, сингапурцы и тайваньцы. Несмотря ни на какие факты, льготы и распилы.
UPD: после написания статьи удалось поговорить с автором слов “Иннополис — лучшее событие за 25 лет”. Это научный сотрудник университета, ставший жителем города одним из первых. Задано было три вопроса:

1. Изменилось ли его мнение по статусу события? Нет, не изменилось, к нему добавилась ещё большая глобальная уверенность, поскольку вслед произошло несколько обнадёживающих событий: например, в научно-технической среде города, так сказать, побратима — Сколково, вместо так и не прижившегося британского профессора Эдварда Кроули, назначен соотечественник Александр Кулешов.
2. Сможет ли Иннополис подтянуться хотя бы к какой-то второсортной кремниевой долине и когда? Резидент уверен, что в течение 5 лет Иннополис будет в лидерах среди проектов, созданных с нуля — вроде Софии-Антиполиса. Если брать в расчёт все показатели, как-то: университет, инфраструктуру и инвестиции, то ждать придётся дольше, но придётся. Ну а Кремниевая долина была и будет уникальной в своём роде.
3. Есть ли Яндекс в Иннополисе и кто из IT-компаний действительно активен в городе? Яндекс есть (и это всё же удивительно — прим. автора). Из крупных и активных — вышеупомянутый Сбертех, Acronis (защита данных), ICL (производитель компьютерной техники), Cognitive Technologies (разработчик программного обеспечения).

Честно — не верится в оптимизм резидента Иннополиса. В России живём же? И не такие проекты гибли. Не верится — но пусть будут правы он и те студенты. Им срочно нужно стать правыми.

https://habrahabr.ru/post/329732/

— Папа, а из чего состоят облака?
— Линукс сервера в основном…

Всем привет, давно что то не брал я в руки пера… По интересному стечению обстоятельств, я устроился работать в компанию которая сотрудничила с другой компанией, в области облачных технологий. На старой работе нужно было отработать 3 месяца и там еще новый год попался, словом, когда я пришёл уже к ним работать оказалось что: во первых, их продали и они теперь часть совсем не маленькой такой компании (названия умышлено не упоминаю дабы не сочли рекламой), а во вторых, облачная компания которая в девичестве звалась Cliqr (кто то может даже знает их по названию стартапа как osmosix) теперь же оказалась частью Cisco и сменила название на CloudCenter.

Поскольку я ничего не нашел тут про эту платформу, а по работе я только с ней теперь и работаю, я решил вам расказать вкратце что это такое, если будет интерес, смогу в следующий раз рассказать и как готовить :) Начну из далека…
Читать дальше →

https://habrahabr.ru/post/329734/

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

В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки IT продуктов»


Читать дальше →

https://habrahabr.ru/post/329716/

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


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

https://habrahabr.ru/post/329724/

В наши дни только ленивый никого ничему не учит. Десятки курсов и тренингов на которых вам обещают “современные фишки” которые сделают из Вас специалиста за 1-2 месяца. Зачем нам 11 лет школы и 5 института? Если есть вариант стать профи по быстрому. Вся проблема в том что в 90% случаев это не работает. Это просто один из видов бизнеса. Не получится стать мастером за 2 месяца. Но хочется верить в чудо и красивый рекламный текст вам в этом помогает.
Читать дальше →

https://habrahabr.ru/post/329726/