ИТ-реальность: инфраструктура и DevOps. Актуальные технологии и снижение рисков

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

1. Особенности облачной инфраструктуры
2. Риски «на облаках»
3. Аутсорсинг при разработке проектов — это хорошо или плохо?
4. Самые популярные стратегии резервного копирования
5. Система мониторинга — необходимость наблюдения за всеми частями проекта
6. 7 основных методологий разработки
7. Плюсы CI/CD/CT

Особенности облачной инфраструктуры

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

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

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

Все это позволяет запускать новые сервисы у большинства поставщиков. Например, у «Ажур» или Yandex Cloud это можно сделать путем обращения в CAPI. Это дает возможность автоматизировано нарастить количество серверов или объем выделенных ресурсов по мере повышения нагрузки. При необходимости от них будет так же легко отказаться.

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

Риски «на облаках»

Следует учитывать, что облачные сервисы накладывают определенные ограничения

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

Защита данных

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

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

Слабая поддержка

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

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

Сложности с резервным копированием

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

Услуги внешнего поставщика инфраструктуры нужно использовать:

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

Основные факторы, которые нужно учитывать при выборе провайдера:

• репутация;
• нахождения в юрисдикции РФ;
• анализ финансовой устойчивости, полученный из открытых источников.

Для подстраховки рекомендуется иметь не одного, а двух провайдеров

Аутсорсинг при разработке проектов — это хорошо или плохо?

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

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

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

Плюсы аутсорсинга

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

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

Самые популярные стратегии резервного копирования

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

• Стратегия «3-2-1»: её применяют, когда необходимо резервировать важные данные. Ее особенность заключается в том, что для любой информации создается минимум 3 резервные копии на 2-х разных носителях, а одна из копий хранится удаленно.
• Стратегия «Дед-Отец-Сын»: ориентирована на корпоративное хранение данных. Полная резервная копия хранится удаленно на хорошо защищённом облаке (это «Дед»). «Отец» — это более частое резервное копирование на локальный носитель. «Сын» — быстрые резервные копии.
• Стратегия «Ханойская башня» математически основана на одноименной игре. Резервная копия распределяется по разным носителям. Это самая сложная, но самая надёжная стратегия резервного копирования.

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

Система мониторинга — необходимость наблюдения за всеми частями проекта

Наблюдение ведётся за всеми аспектами проекта — от утилизации ресурсов до бизнес-показателей. Чтобы сервис работал стабильно, нужно обеспечить его поддержкой 24/7. Для этого необходимо:

• собирать метрики — данные, которые являются показателями производительности проекта;
• проводить анализ результата;
• работать с инцидентами.

Для правильного мониторинга необходимо придерживаться следующего:

• отслеживать только то, что нужно, и не собирать лишнего;
• уведомлять до наступления проблемы.

Основные задачи мониторинга:

• контроль над ошибками приложений;
• наблюдение за доступностью сервисов;
• контроль производительности.

Чтобы сервис не замедлял свою работу, нужно отслеживать:

• загруженность сети и скорость выполнения обработки запросов;
• прогнозирование отказа системы;
• отчётность о работе систем;
• сообщения о проблемах – алертинг.
• инвентаризацию программных средств.

Мониторинг тоже нужно мониторить: если с ним возникнут проблемы, это приведет к возникновению еще более серьёзных проблем. Оповещения высылаются на почту, в Телеграм, по СМС – в зависимости от критичности, важности и времени суток – при возникновении проблем. Если мониторинг «отвалится», сработает «мониторинг мониторинга». Чтобы снизить вероятность падения мониторинга, его необходимо разделить на несколько узлов.

Типичная схема нагруженного узла может быть масштабирована.

Виды масштабирования

Вертикальное

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

• абстрагирование от хост-системы;
• изолирование среды;
• простота развертывания узлов;
• управление версиями и зависимостями;
• компоновка (настройки среды как кода).

Минусы контейнеризации:

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

Горизонтальное

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

Использование систем в роли Ansible/Chef/Puppet

Это система оркестрации. Если нужна какая-то программа, она позаботится о том, чтобы всё было установлено до того, как та потребуется. Это позволяет автоматизировать и ускорить развёртывание приложений. Плейбук описывается один раз, и неважно, сколько раз он запускается: результат всегда будет одинаковым — развернутое приложение.

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

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

7 основных методологий разработки

Выбор ИТ-инфраструктуры также зависит от выбранной методологии разработки. Разберем, какие они бывают.

• Waterfall Model — каскадная модель, заключающаяся в последовательном прохождении стадий, каждая из которых завершается тестированием. Пишется техническое задание, и перед разработчиками ставится задача. Затем она реализуется, а тестирование завершается до начала следующей стадии разработки. Преимущество модели состоит в том, что разработка проходит быстро, ее сроки и стоимость известны заранее, но, если проект имеет не до конца оформленную структуру, применять каскадную модель нецелесообразно, поскольку изменять проект по ней достаточно дорого.
• V-Model — применяется в тех же случаях, но ориентирована на тестирование, которое начинается одновременно с разработкой. Используется для высоконадёжного программного обеспечения.
• Incremental Model — требования системы делятся на различные сборки и терминологию. Применяется в тех случаях, когда требуется выполнить максимально быстрый заход на рынок и есть рисковые идеи.
• RAD Model — быстрая разработка приложений, деление приложения на мини приложения. Это такая же инкрементальная модель, только над проектом могут одновременно работать несколько независимых команд, каждая из которых разрабатывает отдельный модуль, который впоследствии интегрируются. Данное бизнес-моделирование используется, когда есть узкоспециализированный архитектор или проект очень крупный. Это дорогая модель для разработки, которая требует выполнения в сжатые сроки.
• Agile Model — подразумевает полное вовлечение заказчика в разработку. Каждая итерация принимается клиентом, который может менять проект на любом этапе. В этом случае спрогнозировать трудозатраты и стоимость очень сложно, а команда должна обладать экстремальными навыками программирования. Эту модель стоит использовать, когда потребности постоянно изменяются и изменения по данной модели можно реализовать за меньшую стоимость. Она не выглядит как законченное техническое задание и может со временем меняться.
• Iterative Model — практически не отличается от классической модели Waterfall, но не требует полной спецификации требований. Сначала делается набросок, который выполняется, после чего требования уточняются и набросок изменяют. Подходит для очень крупных проектов.
• Spiral Model — подходит для проектов, которые меняются постоянно и непрерывно. Сначала осуществляется планирование, затем анализ и конструирование. Если результат устраивает, планируется следующий элемент развития системы. Применяется в очень сложных и дорогих проектов в больших организациях.

Плюсы CI/CD/CT

Также построение эффективной ИТ-инфраструктуры невозможно без правильной организации процессов доставки функционала продуктов. CI/CD/CT переводится как непрерывная интеграция, доставка и тестирование.

1. Автоматизация шагов доставки приложения от написания кода к конечному пользователю.
2. Упрощение отката и устранение дефектов, повышение качества приложения.
3. Ускорение реализации, уменьшение времени на пути «идея-конечный продукт».
4. В случае комбинации CI/CD/CT разработчики могут действовать гибко. Это ускоряет время вывода продуктов в продакшн.

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

RDN Group оказывает DevOps-услуги Enterprise клиентам, а также командам разработчиков, желающим вынести заботы об инфраструктуре на аутсорсинг. Получите рекомендации от нашего DevOps специалиста: