Милі та пухнасті

Блог

  • Полное руководство Office 365 по безопасности

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

    Microsoft стремится показать, что ваши данные в Office 365 остаются вашими; их никогда не будут анализировать для рекламных кампаний и к вашим данным никогда не будут обращаться иначе как с целью предоставления «облачных» услуг для организации офисной работы. Когда вы оформляете подписку на использование Office 365, вам предъявляется ряд предупреждений о нормативных требованиях с описанием способов управления.

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

    Структура этой статьи очень проста: мы приводим подробное описание различных функций безопасности, соответствия требованиям, администрирования и управления, реализованных в Office 365. Для всех тем избран единый порядок представления:

    • Описание каждой функции управления или защиты данных.
    • Объяснение ее предназначения и способов применения.
    • Источники дополнительной информации.

    Мы уверены, что такой материал будет незаменимым ресурсом для администраторов Office 365 и специалистов по безопасности. Компания Microsoft приложила немало усилий, чтобы по возможности уменьшить опасения относительно безопасности данных в Office 365.

    Обязательно обратите внимание на центр управления безопасностью Office 365 Trust Center — в нем вы найдете подробные объяснения для всех рассмотренных в данной статье тем. На сайте своевременно отражаются все изменения в стандартах, применимых к Office 365, приводятся сведения о новых мерах безопасности и ссылки на многие национальные и международные сертификаты, выданные «облачной» платформе.

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

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

    Как Office 365 обеспечивает безопасность

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

    В основе Office 365 лежат одни из самых надежно защищенных центров обработки данных в мире, соответствующие составленным в компании Microsoft требованиям жизненного цикла разработки защищенных приложений Security Development Lifecycle (SDL). Многие методики складывались десятилетиями, и в течение этого времени Microsoft вела собственные разработки корпоративного программного обеспечения, так что начиная с конца 1990-х эти усилия охватывали многочисленные веб-службы.

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

    Microsoft постоянно повышает уровень безопасности платформы Office 365, от сканирования портов и периметра до регулярного аудита действий и доступа оператора или администратора. Если вы хотите быть в курсе шагов, предпринимаемых Microsoft для защиты данных, советуем обратить внимание на сайт Office 365 Roadmap  (https://products. office.com/en-US/business/office-365-roadmap) и время от времени посещать его, чтобы следить за свежими обновлениями.

    Физическая безопасность

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

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

    Логическая безопасность

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

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

    Безопасность данных

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

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

    Каким образом Office 365 управляет соответствием требованиям?

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

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

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

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

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

    В Office 365 используется инфраструктура управления, в которой реализован стратегический подход к внедрению обширных функций контроля соответствия стандартам, которые в свою очередь удовлетворяют различным отраслевым нормативам. Office 365 поддерживает более 600 функций управления, которые позволяют Microsoft обеспечить соответствие сложным стандартам и предложить контракты клиентам из регулируемых отраслей, такие как ISO 27001, типовые регламенты ЕС, соглашения о деловых партнерах HIPAA Business Associate Agreements и FISMA/FedRAMP.

    Кроме того, Microsoft использует исчерпывающее соглашение об обработке данных для решения проблем конфиденциальности и безопасности, касающихся данных клиентов, помогая клиентам обеспечить соответствие местным нормативным актам. Дополнительные сведения по этой теме можно получить в статье с вопросами и ответами по обеспечению соответствия требованиям нормативных документов Microsoft (https://www.microsoft.com/online/ legal/v2/en-us/MOS_PTC_ Regulatory_Comp.htm).

    Чтобы предоставить клиентам возможность наиболее полного контроля над соответствием требованиям в Office 365, Microsoft разработала три полезные службы.

    • Предотвращение потери данных (DLP). DLP — стратегия и инструментарий, которые помогают администраторам управлять потоком конфиденциальной или критически важной информации вне корпоративной сети. С помощью DLP администраторы могут настраивать политики в зависимости от нужд своей компании в сфере соответствия требованиям, чтобы уменьшить вероятность случайного разглашения финансовой информации, персональных данных (PH) или иных важных сведений об интеллектуальной собственности. Подсказки политики DLP размещают уведомления непосредственно в электронной почте пользователя, предупреждая его о потенциальных опасностях перед отправкой сообщения электронной почты. Эти уведомления могут также использоваться как образовательное средство для ознакомления сотрудников с корпоративными политиками соответствия требованиям.
    • Центр eDiscovery. Обнаружение электронных данных (eDiscovery) — процесс, с помощью которого можно вести поиск, обнаруживать и защищать электронные записи с целью их использования при разрешении юридических вопросов. Эти возможности Office 365 позволяют искать информацию на сайтах SharePoint Online, почтовых ящиках Exchange Online, учетных записях One Drive для бизнеса или во всех перечисленных хранилищах сразу. Центр eDiscovery позволяет создавать «досье», которые обеспечивают пространство взаимодействия для сбора ключевых элементов, необходимых для формирования доказательной основы. С помощью eDiscovery в Office 365 можно обнаруживать любую информацию, сохраненную в данной среде, в том числе архивированные сообщения электронной почты.
    • Управление записями сообщений Messaging Records. Management (MRM) — внутренняя технология хранения данных в Office 365. Параметры настройки позволяют применять политики управления записями как к содержимому Exchange Online, так и к SharePoint, чтобы указать информацию, которую следует сохранить, и информацию, потребности в которой больше нет. Ведение журнала и подготовка отчетов аудита позволяют отслеживать все что угодно, от действий администратора до доступа к документам и их удаления. Предусмотрено много функций ведения журнала и подготовки отчетов, которые могут быть настроены в соответствии с конкретными нуждами. Сочетание архивации электронной почты и механизма eDiscovery может облегчить задачу пользователям и администраторам за счет сокращения объема работы по организации папки “Входящие” и автоматического применения политики хранения данных на основе типа используемой информации. Дополнительное преимущество архивации заключается в том, что вашим пользователям не приходится сортировать свои почтовые сообщения в независимых архивных файлах на локальных системах, которые могут располагаться за пределами вашего ИТ-подразделения.

    Мы можем помочь перенести в облако корпоративную ИТ инфраструктуру и внедрить Office 365. Свяжитесь с нами office@itfb.com.ua

  • Как мы используем SonarQube для оптимизации разработки ПО

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

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

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

    Принцип работы

    Как SonarQube работает? Разработчик пишет код, пишет код либо в блокноте, либо в IDE. Для IDE, PyCharm, Studio и Eclipse есть плагин SonarLint.

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

    Разработчик написал свой кусок кода он его пушит в систему хранения вируса. У нас используется git (gitLab) для этого. После того как код оказался в gitlab, вступает в действие CI – система, у нас используется TeamCity.

    В шаг сборки встроен шаг анализирования исходников, SonarQube анализирует исходники непосредственно в билд машине и отправляет свой отчет на SonarQube – сервер.

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

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

    Некоторые плагины, на слайде помеченные знаком $, имеют платные версии, остальные доступны бесплатно. В т.ч. один из самых популярных языком программирования С++ – официальный плагин разработчиков он платный и стоит довольно заметную сумму.

    Какие типы проблем находит SonarQube?

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

    Метрики, которые Sonar снимает с анализируемого кода

    • Reliability – надежность. Надежность проекта основана на количестве дефектов логики. Чем меньше дефектов логики, тем выше надежность проекта.
    • Security – тоже самое по уязвимостям, по vulnerability. Чем их меньше, тем безопаснее код.
    • Maintainability – поддерживаемость. Тоже самое, касающееся элементов плохого кода. Чем меньше плохого кода, тем легче проект поддерживать.
    • Duplications – повторение. Оценка количества повторений. Измеряются повторения строк кода, повторение блоков кода либо повторение целых файлов кода.
    • Complexity – сложность. Сложность проекта оценивается количеством ветвлений в коде. Чем больше ветвлений в коде, тем сложнее проект.
    • Documentation – оценка количества комментариев в коде. Насколько хорошо классы, методы, функции покрыты комментариями.
    • Issues – проблемы. Это информация по всем проблемам, информация о статусе, типе.
    • Tests – Оценка покрытия кода тестами.
    • Quality Gates – итоговая оценка качества проекта. Данная итоговая оценка может иметь статусы: fail, partial success или success. Т.е. проект может целиком/частично удовлетворять качеству либо не удовлетворять совсем.

    Рассмотрим на примере данные метрики. Вы можете увидеть Reliability, количество багов и оценку. Тоже самое по Security, Maintainability. По Duplications оценка идет по количеству блоков, по количеству линий, по количеству файлов.

    Complexity – опять-таки количество ветвлений. Documentation – количество комментариев и процент покрытия комментариями кода. И Issues – видим сколько их всего, сколько проблем, и сколько добавлено новых с момента последнего анализа.

    Ну и самое интересное – это как раз Quality Gates. Это то, куда мы попадаем, когда завершается анализ, когда в CI-системе выдается ссылка на результат анализа. В данном случае мы видим провальный Quality Gates.

    С какими проблемами мы столкнулись при эксплуатации Sonar, а также, чего мы добились

    Первая проблема

    Некорректная работа с LDAP-группами. Т.е. сотрудников достаточно много, авторизация под доменами и учетками проходит хорошо.

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

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

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

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

    Вторая проблема

    Высокая стоимость плагинов. Один из самых востребованных плагинов по С++ стоит достаточно дорого. Несколько тысяч долларов. Это было неприемлемо. Из этого положения вышли, скармливая отчеты ЦП по чеку SonarQubе.

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

    Третья проблема

    Отсутствие иерархичности проектов. Если в системе контроля версии лежит какой-то проект, и у него есть n-ое количество веток, то в Sonar этот проект будет выглядеть просто как множество проектов по имени проекта и имени ветки.

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

    Профит использования SonarQubе

    В “бою” мы используем Sonar уже около полугода. Собственно, по обратной связи по данным с сервера приведу небольшую статистику, без цифр:

    1. Качество нового кода повысилось. Со временем уже приходили все более-более лучшие анализы. Проекты стали чаще соответствовать Quality Gate..
    2. Найдены старые баги уязвимости. Даже в проекте, в котором код уже давно не менялся, казалось бы уже проверен годами, нашли несколько багов, пофиксили их, и все стало замечательно.
    3. Сократилось время, затрачиваемое на ревью кода. Т.е. ревьювер теперь не смотрит стиль, не смотрит какие-то другие метрики. Он просто смотрит приблизительно логику, что код, который написан человеком, подходит. Далее уже все делает Sonar, т.е. стилистику и прочее он замечательно у нас распознает.
    4. Повысилась культура написания кода в общем. Т.е. это по фидбэку от разработчиков было понятно, что теперь они стараются писать несколько лучше: и по стилистике и в общем ответственно относиться к написанию кода.

    Мы можем повысить автоматизацию разработки внедрением технологии SonarQube. Это поможет улучшить качество программных продуктов и ускорить их релиз. Обращайтесь на office@itfb.com.ua

  • Принципы виртуализации серверов

    Принципы виртуализации серверов

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

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

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

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

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

    Основные определения

    • Гипервизор типа I (рис.1). Он развертывается на компьютере без операционной системы. Таким образом , это первый про­граммный продукт, устанавливаемый на сервере. Он будет напрямую взаимодействовать с аппаратными средствами физического сервера. Затем эти ресурсы паравиртуализуются и предо­ставляются работающим виртуальным машинам. Это предпо­чтительный метод для многих производственных систем.
      Гипервизор типа I для виртуализации серверов
    • Гипервизор типа II (рис.2). Эта модель, показанная на рисунке 2, также известна как хостируемый (hosted) гипервизор. Программа устанавливается не на “голом” железе, а поверх действующей операционной системы.Например, на сервер с Windows Server 2008 R2 поверх операционной системы может быть установлен гипервизор VMware Workstation 8. Появляется допол­нительный уровень программного обеспечения, через который передаются вычислительные ресурсы, прежде чем они достигнут вир­туальной машины, но задержка минимальная, и благодаря совре­менным усовершенствованиям производительность гипервизора может оставаться оптимальной.
      Гипервизор типа II для виртуализации серверов
    • Гостевая машина или виртуальная машина, представляет собой рабочую нагрузку, то есть рабочее прило­жение, устанавливаемое поверх гипервизора. Это может быть виртуальное устройство, операцион­ная система или виртуализуемая рабочая нагрузка другого типа. Гостевая машина исходит из того, что является самостоятельным компьютером с собственными выделенными устройствами. Таким образом, благодаря вир­туализации вы можете использо­вать один физический компьютер для выполнения нескольких рабочих нагрузок . Все это про­исходит при интеллектуальном распределении ресурсов между виртуальными машинами.
    • Хост-компьютер. Это физический сервер. Виртуализация может охватывать несколько компонентов — сети хранения SAN, локальные сети, проводные соединения и т.д., но в данной статье мы сосредоточимся на ресурсах физического сервера. Основные ресурсы — оперативная память и процессор — делятся между виртуальными машинами и распределяются по усмотрению администратора. Машина, которой требуется больше оперативной памяти (например, контроллер домена), получит больше ресурсов, а менее важная виртуальная машина (скажем, сервер лицензий) будет иметь меньше ресурсов. Благодаря современным технологиям гипервизоров многие ресурсы можно выделять динамически.
    • Инструменты паравиртуализации. После установки гостевой виртуальной машины поверх гипервизора на этой виртуальной машине обычно устанавливается набор инструментов. Они предоставляют набор операций и драйверов для оптимизации работы гостевых виртуальных машин. Например, хотя собственные драйверы для сетевой платы будут работать, взаимодействие паравиртуальных драйверов сетевой платы с базовым физическим уровнем будет гораздо более эффективным и обеспечит сложные сетевые технологии работы.
    • Контейнеры. Эта технология все чаще используется совместно с традиционными гипервизорами, такими как VMware или XenServer, или вместо них. Виртуализация уровня операционной системы — превосходный инструмент для создания надежно изолированных многоабонентских сред.

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

    Это важно, поскольку вы можете, например, запустить контейнер Microsoft IIS, не выделяя целиком виртуальную машину или лицензию операционной системы. Вы непосредственно запускаете только контейнер I IS. Аналогично другие поставщики, такие как Citrix со своей NetScaler СРХ, могут запускать мини-ADC в контейнерной среде.

    Интеграция становится все более тесной. Среда Microsoft Azure дополнена поддержкой контейнеров Docker на виртуальных машинах Linux, что позволяет обширной экосистеме «докеризованных» приложений Linux работать в «облаке» Azure.

    При еще более глубоком внедрении «облака» системы контейнеров, использующие Docker, также могут быть интегрированы с платформами Chef, Puppet, OpenStack и Amazon Web Services. Red Hat тоже вступил в игру, оснастив Docker таким передовым инструментарием Linux, как systemd и SELinux.

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

    Наконец, основные поставщики гипервизоров также предоставляют передовые службы контейнеров. Среди них три наиболее важных: VMware vSphere, Microsoft Hyper-V и Citrix XenServer.

    Профессионально реализовать виртуализацию серверов поможет команда специалистов с 10-и летним опытом. Пишите нам office@itfb.com.ua

  • Процесс внедрения DevOps в деталях

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

    Внедрение DevOps помогает улучшить результаты и производительность компании на всех этапах разработки. Этот факт подтверждается отзывами ряда известных директоров. Например, в Duke Energy результаты улучшились в 10 раз.

    Планирование на замену аналитике

    Процесс внедрения DevOps затрагивает все аспекты разработки. Несмотря на следование принципам Agile, разработка будет занимать огромное количество времени, уменьшая объем релизов в отведенный период. Соответственно, сокращается цикл обратной связи, предназначенный для дальнейшей оптимизации ПО.

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

    Для автоматизации разработки ПО необходимо проводить не только аналитику, но и четко определять объем планируемых работ, с указанием конкретных временных рамок. Это и есть планирование. Таким образом, мы получаем несколько команд, которые выполняют определенную работу в указанный срок, имея яркое представление о том, что от них требуется.

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

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

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

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

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

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

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

    Финансирование DevOps

    Финансирование DevOps – крайне деликатная тема. Если брать во внимание старую модель работы, то сразу заметна проблема, связанная с приобретением необходимого оборудования.

    На это нужны немалые средства. А к этому нужно прибавить и объём капитальных вложений (CAPEX). Всем этим ИТ-департаменты занимались самостоятельно. Сейчас же, следуя принципу DevOps и используя ИТ аутсорсинг, можно сократить расходы благодаря доступным публичным облачным сервисам. Все это переносится на операционные расходы (OPEX).

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

    Уйти в минус легко, несмотря на существенное сокращение затрат. Это связано с растущими счетами в момент production-этапа у больших проектов. Если вам нужно огромное количество серверов, то куда логичнее создать свой ЦОД, чем арендовать их на стороне. Конечно, все зависит от конкретного случая.

    Уменьшение тикетов

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

    Ускорение процесса CAB

    Любой релиз проекта связан с этапом прохождения комитета по изменениям (САВ). Да, их польза – это предмет многих споров, но перед нами стоит задача ускорить процесс. А значит, нужно реализовать конвейер для автоматизированной разработки ПО.

    Полезными инструментами в данном случае станет Chef’s InSpec. Он поможет сократить время проверки и быстрее перейти к production. Автоматизировать процесс можно и с помощью Cloud Foundry или Red Hat Open Shif.

    Старт процесса

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

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

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

    Дальнейшая оптимизация

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

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

  • Ускоряем сайт с PageSpeed

    Ускоряем сайт с PageSpeed

    PageSpeed Insights – инструмент Google для оценки скорости работы сайта. Недавно Google обновил свой инструмент, который позволяет анализировать содержимое сайта и предлагает различные решения, которые позволять оптимизировать, ускорить работу сайта. Данные google получает из собранной статистики посетителей с Chrome и не только. скорость загрузки сайта

    Кроме ранее имеющихся данных, теперь Google обновить их еще и данными с Chrome User Experience, который был запущен в октябре.

    Для большинства сайтов рекомендации по оптимизации имеет следующий вид:

    • Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы
    • Не используйте переадресацию с целевой страницы
    • Используйте кеш браузера
    • Включите сжатие

    Не знаете как это сделать, тогда обращайтесь office@itfb.com.ua, наши специалисты выполнять все рекомендации и сделают Ваш сайт быстрее.

  • Глобальные проблемы перехода на PHP 7: «пациент скорее жив»?

    Глобальные проблемы перехода на PHP 7: «пациент скорее жив»?

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

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

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

    Предпосылки

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

    Напомним, что на данный момент самыми свежими версиями являются 7.1 и 7.2, которые получили выдающуюся поддержку со стороны производителя – частый и оперативный багфиксинг, а также исправления уязвимостей.

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

    Эксперты провели исследование, задачей которого было определить, какие модификации PHP наиболее популярны при обслуживании серверов, и каков процент их пользователей в разных странах. Анализ был проведен для клиентов Plesk, и касался 2 последних ее релизов, что составило около 15% веб-ресурсов на этой платформе.

    Отметим, что к этому времени версии PHP 5.6 и 7.0 получили вендорную отметку “security_fixes_only”, то есть, обновления для них включают только коррекцию существенных проблем с уязвимостью.

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

    Что там у «соседей»?

    Диграмма использования различных версий PHP в администрировании серверов

    Из диаграммы понятно, что рекомендованные последние версии вообще оказались на нижних позициях. Самые удручающие показатели использования старых версий PHP у Китая и Мексики. В частности, в Китае на 4.4 версии работает целых 44 % сайтов, а в целом на устаревших модификациях – 77 %. В Мексике, кстати, этот процент достигает 78%.

    Статистика перехода на PHP 7 по Китаю

    Наиболее прогрессивными странами, которые демонстрируют максимальную часть сайтов на PHP последних версий, стали Южная Корея (85% на 5.6 и новее), Чехия (84%), Швеция (83%). Теперь оценим картинку в разрезе их использования в разных странах, в частности тех, где больше всего применяется Plesk.

    Процент сайтов Германии, использующих в администрировании серверов новые версии PHP

    Статистика использования новых версий PHP в США

    Диаграмма использования новых версий PHP для администрирования серверов Испании

    Популярность различных версий PHP в разных странах

    У нас ситуация не лучше

    Что касается просторов бывшего Советского Союза – в России и Украине 1-е место заняла 5.4 модификация (45 и 24 процентов сайтов). Их опередила Беларусь, где на 1-е место вышла версия 5.6 (40 процентов), и Казахстан с версией 5.5 (32 процента).

    Применение новых версий PHP для администрирования серверов в РФ

    Выводы

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

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

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

    Мы оказываем комплекс услуг по администрированию серверов, реализуем переход на более новую версию PHP, где устранены уязвимости и баги предыдущих версий. Обращайтесь office@itfb.com.ua

  • Мониторинг микросервисов: зачем это нужно

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

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

    С чего начать

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

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

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

    1. Необходимо обеспечить SLA (соглашение о качестве сервиса) для каждого сервиса.
    2. Необходимо анализировать входящие запросы сервисов вместе с параметрами их реакции.
    3. Необходимо анализировать исходящие запросы от одних сервисов к другим вместе с параметрами их реакции.

    Обеспечение SLA

    Данный сервис важен с точки зрения удовлетворения пользователей предоставляемыми ИТ-услугами. С помощью SLA они будут иметь четкое представление о том, с чем им приходится работать и отвечает ли используемый продукт их требованиям. За счет доступности описания и использования общих параметров, все это можно использовать и для других сервисов.

    Речь идет о параметрах SLI (параметры качества сервиса), о которых вы можете в деталях узнать на Wikipedia.

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

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

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

    Мониторинг входящих запросов

    Администрирование серверов необходимо для мониторинга входящих запросов с целью определения степени нагрузки.

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

    Мониторинг исходящих запросов

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

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

    Мониторинг сервисов и их исходящих запросов также позволяет составлять статистику активности и сопоставлять её с деятельностью компании в целом.

    Итог

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

    Мы готовы предоставить услуги профессионального мониторинга серверов и сайтов. Пишите нам office@itfb.com.ua

  • Обзор оптимизированной версии средства для нагрузочного тестирования серверов JMeter

    Текущий год ознаменовался множеством полезных релизов для разработчиков IT-продуктов, из которых особенно заметным стал выпуск новой, 4.0 версии популярного инструментария JMeter для нагрузочного тестирования серверов. Данная версия является удачной, и ее производство проходило на фоне выпусков нескольких провальных версий в течение последних 2-х лет.

    Чем привлекает JMeter 4.0?

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

    Что улучшилось в плане удобства использования?

    • Образ интерфейса, задаваемого по умолчанию “освежили”, реализовав его в затемненном цветовом спектре. Впрочем, возврат к первоначальной теме легко реализуется с помощью соответствующей опции меню “LookAndFeel”.
    • К сожалению, интерфейс средства нагрузочного тестирования JMeter пока не снабжен всеми языковыми решениями. В качестве основного языка предлагается по умолчанию использовать английский. Доступные языки можно выбрать через опционарное меню, кликнув на “Choose Language”.
    • Обновление средства для нагрузочного тестирования затронуло порядок демонстрации пользователю управленческих инструментов. Теперь, как только вы открываете их список, “самые полезные” (часто используемые) будут располагаться в начале списка. Хорошее решение, чтобы еще больше упростить и ускорить разработку новых тестировочных сценариев и улучшить обслуживание серверов.

    Что улучшилось в составе элементов?

    Интегрирован новый компонент JSONAssertion, с помощью которого проверяются соответствующие документы. В отличие от ранних версий, теперь его не нужно отдельно устанавливать в качестве плагина. В 4.0 он становится частью ядра с открытым доступом к коду. То есть, JMeter снабжен полноценным функциональным комплексом, к которому не придется искать и внедрять дополнения что облегчит обслуживание серверов. Проверка осуществляется в 3 этапа:

    • определение принадлежности документа к категории JSON;
    • поиск нужных путей;
    • поиск требуемых значений.

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

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

    • извлечение значений;
    • создание строки;
    • сохранение результата в переменную;
    • последующая настройка переменной в определенном поле элемента.

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

    Что улучшилось в тестовом запуске?

    1. Реализована поддержка Java 9, при этом сохраняется возможность работы с предыдущей версией.
    2. Из интерфейса удален Workbench, который ранее лишь путал пользователей при работе со скриптами. Элементы, ранее размещавшиеся в его scope, могут вноситься в Тест-План.
    3. Автоматическое сохранение Тест-Плана. Теперь пользователя не будут беспокоить всплывающие окна с “напоминалками” о необходимости сохранения изменений.

    Что улучшилось для элементов?

    1. Сэмплер MSPoint-to-point получил новые возможности: read, browse, clean.
    2. Совмещена диагностика серверного ответа и информации о запросе.
    3. Интерпретация условия, как выражения переменной для If инициируется автоматически.
    4. Кэширование скриптов после завершения компиляции для JSR223 также автоматизировано.
    5. Loop и ForEach сберегают данные о нумерации текущей итерации в формате __jm__<Имя вашего элемента>__idx.

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

    Мы можем провести аудит ИТ инфраструктуры на предмет ее соответствия нагрузкам. Предложим и реализуем улучшения. Пишите нам office@itfb.com.ua

  • Сертификация PCI DSS

    Сертификация PCI DSS

    Существует несколько сертификаций, которые позволяют компаниям осуществлять деятельность, связанную с электронными платежами. Но самой популярной на территории СНГ является стандарт PCI DSS.

    Сертификат PCI DSS (Payment Card Industry Security Standards Council) дает возможность не только соответствовать последним требованиям безопасности, но и оптимизировать работу всей инфраструктуры.

    Ниже перечислены основные пункты, которым должна соответствовать компания для прохождения проверки по PCI DSS. Всего их 12, и группируются они на 6 категорий:

    Критерии для получения сертификата PCI DSS

    Какие преимущества дает PCI DSS

    Помимо очевидного технологического толчка для развития компании, сертификат PCI DSS повышает её имидж. С одной стороны, инфраструктура становится более безопасной, а с другой, это улучшает отношение клиентов к предоставляемым услугам.

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

    Так что, сертификат PCI DSS – это не только современные средства защиты, но и залог успешной репутации компании.

    Хостинг PCI DSS

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

    Статистика обращений за сертификатом PCI DSS к официальным поставщикам

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

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

    Однако, новые тенденции позволяют компаниям отходить от физической локализации данных, используя серверную инфраструктуру (IaaS). Самые продвинутые компании позволяют своим пользователям не только хранить данные, но и осуществлять их администрирование, не нарушая требования стандарта PCI DSS.

    Современные тренды на рынке

    Согласно проведенному анализу работающих компаний, большинство представителей использует услуги сертифицированных поставщиков извне для оптимизации безопасности инфраструктуры, используя выделенные дата-центры. Но многие идут дальше и внедряют расширения для PCI DSS IaaS вместе с управляемыми сервисами MSP.

    Статистика соответствия стандарту PCI DSS крупнейших российских компаний

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

    Одной из таких компаний стала «ИТ-ГРАД». Она дала возможность другим учреждениям и, соответственно, клиентам пользоваться всеми преимуществами стандарта PCI DSS. Уровень доверия со стороны пользователей к всему, что имеет данный логотип, неустанно растет, а значит, увеличивается спрос на услуги.

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

    Если вы не уверены в соответствии своей фирмы критериям стандартам PCI DSS, обращайтесь. Мы проанализируем инфраструктуру и приведем ее в соответствие нормам сертификации.

  • Автоматизация развертывания тестовых окружений средствами Ansible на PVE

    Автоматизация развертывания тестовых окружений средствами Ansible на PVE

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

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

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

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

    Дополнительным ограничением при выборе технологий выступил факт внедренной и успешно используемой системы управления виртуализацией Proxmox Virtual Environment (PVE).

    Ориентированная на простоту использования, она не имеет готового инструментария для создания и управления достаточно сложными конфигурациями, которые требовались для решения наших задач. Например, на момент начала реализации нашего проекта PVE не имел API для управления параметрами Cloud-Init.

    Выбор пути решения

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

    С другой стороны, можно взять чистый REST-API Proxmox, обвешаться шелл-скриптами, которые будут разворачивать окружения, а все, что нельзя сделать через REST, делать скриптами через ssh. Это решение самое быстрое и в большинстве случаев еще и рабочее, но его масштабирование на возросшие потребности в будущем, как правило, требует достаточно больших переработок в дизайне и кодовой базе.

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

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

    Разработка дизайна

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

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

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

    Далее рассмотрим их более подробно.

    Приложения

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

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

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

    Ноды должны обеспечивать возможность доставлять сообщения от одних приложений к другим. Часто это обеспечивается посредством TCP/IP в среде Ethernet, и это тоже требует отдельной непротиворечивой и воспроизводимой конфигурации. Множество нод с их конфигурацией называется «стек» или «stack».

    Стеки

    Стек (stack) – описание множества (не пустого) нод и их конфигураций, необходимых для установки и функционирования приложений.

    Конфигурация нод включает в себя:

    • тип платформы: голое железо, Proxmox (QEMU), LXC, etc.
    • архитектура: х86, х86_64, Elbrus, etc.
    • количество ядер процессора;
    • ограничение по оперативной памяти;
    • количество и параметры сетевых интерфейсов;
    • имя образа или шаблона, из которого будет развернута среда исполнения;
    • описание и параметры необходимых сетевых интерфейсов.

    И еще множество дополнительных параметров, если они необходимы в конкретном случае.

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

    Например, достаточно легко описать стек из одного сервера с контроллером домена, трех реплик, двух клиентов на базе десктопного дистрибутива, и двух клиентов на базе серверного дистрибутива.

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

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

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

    Окружение

    Окружение (env) – это набор параметров, общих для всего стека. Как правило, это адрес локального зеркала пакетов, параметры доступа к Proxmox, список нод, на которых можно разворачивать контейнеры той или иной архитектуры, список ssh-ключей, которые необходимо зарегистрировать на всех нодах кластера.

    Реализация

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

    Первая проблема, которая появилась в самом начале, – как хранить секретные данные и обеспечить к ним доступ всех членов команды?

    Простая ситуация: у нас есть сервер Proxmox, на нем мы хотим разворачивать тестовые стенды как руками с ноутбуков разработчиков, так и автоматически в рамках CI. В процессе деплоя необходимо создавать пользователей домена с паролями, задать пароль для администратора и использовать прочие данные, которые посторонним показывать нельзя. С другой стороны, нам необходимо иметь возможность передавать проблемную конфигурацию заинтересованным лицам. В идеале она должна быть передана через открытые каналы, например через публичный git-репозиторий.

    Решение, примененное нами, состоит из двух частей. Поля с секретными данными в самой конфигурации мы шифруем через стандартный механизм ансибла Ansible Vault симметричным ключом, этот ключ кладем в базу утилиты pass, в которой он шифруется асимметричными PGP-ключами всех заинтересованных лиц.

    После этого мы можем публиковать и конфигурацию, и базу pass на публичных ресурсах.

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

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

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

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

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

    В качестве альтернативы был реализован метод поэтапной установки. Так называемые шаги или steps. В общем виде он представляет собой список списков пар (сервис, нода). Задачи из нижнего списка будут исполнены параллельно, но эти списки будут перебираться последовательно и в строго заданном порядке.

    В данном примере (см. рис. 3) мы хотим сначала развернуть контроллер домена на ноде dc0, после успешного завершения мы разворачиваем три контроллера домена в режиме реплики dc1, dc2, dc3 и параллельно с ними разворачиваем два клиента домена на нодах сI0 и clw0.

    Для ввода клиентов в домен достаточно одного рабочего контроллера, поэтому можно сократить время деплоя, устанавливая клиентов одновременно с репликами. И в последнем, третьем, шаге мы добавляем еще одну реплику на ноде dc4.

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

    Несколько слов о том, откуда взялись ноды dc0, dc1, clw0 и т.д. За их появление отвечает стек. На рис. 4 представлен пример конфигурации шести однотипных нод.

    Интересным моментом тут являются поля count и ipv4 в параметрах сетевого интерфейса. Фактически мы описываем, что хотим три ноды с именами dc0, dc1. dc2 (имена будут сгенерированы из имени ключа dc и порядкового номера 0..count-1), поднять их нужно на PVE по два ядра на каждую ноду и по гигабайту памяти.

    Также необходимо добавить два сетевых интерфейса eth0 и eth1. Первый должен входить в 994-й VLAN на мосту vmbrl, и адреса должны быть назначены начиная с 10.64.84.1. То есть нода dc0 будет иметь адрес 10.64.84.10, нода dс1 – 10.64.82.11 и т.д. Второй интерфейс по аналогии, только другой VLAN-тег и другие адреса. Ноды для клиентов конфигурируются по аналогии, но разворачиваются с другого шаблона (параметр template).

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

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

    Решение, которое было применено, основывается на проекте Packer. Вокруг него написана обвязка, которая позволяет полностью автоматизировать подготовку образов для VirtualBox и Qemu, основываясь на официально опубликованных ISO-образах дистрибутива, и затем размещать готовые образы на серверах PVE или заливать на VagrantCloud.

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

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

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

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

    Частично эта задача тоже решена. Но уже сейчас видно, что некоторые вещи можно сильно упростить и сделать понятнее. Приятным дополнением явилось то, что гибкость получившегося инструмента позволила нам применить его и для развертывания продакшн инфраструктуры с необходимыми нам сервисами bind, dhcp-сервера, tftp, nginx и т.д., вся конфигурация которых лежит под управлением git, любое изменение подвергается code-review, и заинтересованные лица в любой момент могут посмотреть, кто и когда внес те или иные изменения, и при необходимости откатить всю инфраструктуру на любое прошлое состояние.

    Планы на будущее

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

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