Понятие облачных вычислений.

Плюсы и
минусы облаков.
Облачные вычисления (англ. cloud computing) — технология распределенной
обработки данных, в которой компьютерные ресурсы и мощности предоставляются
пользователю как Интернет-сервис. Предоставление пользователю услуг как
Интернет-сервис является ключевым. Однако под Интернет-сервисом не стоит
понимать доступ к сервису только через Интернет, он может осуществляться также и
через обычную локальную сеть с использованием веб-технологий.
Плюсы:
● доступность – облака доступны всем, из любой точки, где есть Интернет, с
любого компьютера, где есть браузер. Это позволяет пользователям
(предприятиям) экономить на закупке высокопроизводительных, дорогостоящих
компьютеров. Также сотрудники компаний становятся более мобильными так,
как могут получить доступ к своему рабочему месту из любой точки земного
шара, используя ноутбук, нетбук, планшетник или смартфон. Нет
необходимости в покупки лицензионного ПО, его настройки и обновлении, вы
просто заходите на сервис и пользуетесь его услугами заплатив за фактическое
использование.
● низкая стоимость – основные факторы снизившие стоимость использования
облаков следующие:
○ снижение расходов на обслуживания виртуальной инфраструктуры,
вызванное развитием технологий виртуализации, за счет чего требуется
меньший штат для обслуживания всей ИТ инфраструктуры предприятия;
○ оплата фактического использования ресурсов, пользователь облака
платит за фактическое использование вычислительных мощностей
облака, что позволяет ему эффективно распределять свои денежные
средства. Это позволяет пользователям (предприятиям) экономить на
покупке лицензий к ПО;
○ использование облака на правах аренды позволяет пользователям
снизить расходы на закупку дорогостоящего оборудования, и сделать
акцент на вложение денежных средств на наладку бизнес процессов
предприятия, что в свою очередь позволяет легко начать бизнес;
○ развитие аппаратной части вычислительных систем, в связи с чем
снижение стоимости оборудования.
● гибкость — неограниченность вычислительных ресурсов (память, процессор,
диски), за счет использования систем виртуализации, процесс
масштабирования и администрирования «облаков» становиться достаточно
легкой задачей, так как «облако» самостоятельно может предоставить вам
ресурсы, которые вам необходимы, а вы платите только за фактическое их
использование.
● надежность – надежность «облаков», особенно находящихся в специально
оборудованных ЦОД, очень высокая так, как такие ЦОД имеют резервные
источники питания, охрану, профессиональных работников, регулярное
резервирование данных, высокую пропускную способность Интернет канала,
высокая устойчивость к DDOS атакам.
 ● безопасность – «облачные» сервисы имеют достаточно высокую безопасность
при должном ее обеспечении, однако при халатном отношении эффект может
быть полностью противоположным.
● большие вычислительные мощности – вы как пользователь «облачной»
системы можете использовать все ее вычислительные способности, заплатив
только за фактическое время использования. Предприятия могут использовать
данную возможность для анализа больших объемов данных.
Минусы:
● постоянное соединение с сетью – для получения доступа к услугам «облака»
необходимо постоянное соединение с сетью Интернет. Однако в наше время
это не такой и большой недостаток особенно с приходом технологий сотовой
связи 3G и 4G.
● программное обеспечение и его кастомизация – есть ограничения по ПО
которое можно разворачивать на «облаках» и предоставлять его пользователю.
Пользователь ПО имеет ограничения в используемом ПО и иногда не имеет
возможности настроить его под свои собственные цели.
● конфиденциальность – конфиденциальность данных хранимых на публичных
«облаках» в настоящее вызывает много споров, но в большинстве случаев
эксперты сходятся в том, что не рекомендуется хранить наиболее ценные для
компании документы на публичном “облаке”, так как в настоящее время нет
технологии которая бы гарантировала 100% конфиденциальность хранимых
данных.
● надежность – что касается надежности хранимой информации, то с
уверенностью можно сказать что если вы потеряли информацию хранимую в
“облаке”, то вы ее потеряли навсегда.
● безопасность – “облако” само по себе является достаточно надежной системой,
однако при проникновении на него злоумышленник получает доступ к
огромному хранилищу данных. Еще один минус это использование систем
виртуализации, в которых в качестве гипервизора используются ядра
стандартные ОС такие, как Linux, Windows и др., что позволяет использовать
вирусы.
● дороговизна оборудования – для построения собственного облака компании
необходимо выделить значительные материальные ресурсы, что не выгодно
только что созданным и малым компаниям.

Характеристики облачных вычислений. Меры

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

Что такое SLA. Сценарии применения

облачных вычислений.
SLA (англ. Service Level Agreement – соглашение об уровне сервиса) – это соглашение
между заказчиком и исполнителем о том, какие, когда и как будут предоставляться
услуги. Также в него входят права и обязанности сторон. Используется SLA в IT и
сфере телекоммуникаций.
Этот термин относится к методологии ITIL (англ. IT Infrastructure Library – библиотека
инфраструктуры информационных технологий), в которой описываются лучшие
способы организации работы компаний, предоставляющих IT-услуги.
Простыми словами, SLA – это договор, в котором подробно описаны предоставляемые
услуги, их качество, время реагирования на заявку и ее исполнение.
В попытке стандартизировать и предоставить рекомендации по составлению
соглашения об уровне обслуживания Европейская комиссия начала продвижение
документа, целью которого является обеспечение большей прозрачности для
бизнесов при работе с облачными сервисами и изучении SLA. Инициатива получила
название SLALOM и, как отмечает CIF, она позволит «снизить неопределенности» при
миграции инфраструктуры в облако.
Разберем несколько первоочередных пунктов, на которые следует обратить внимание
провайдеру при составлении своего соглашения об уровне обслуживания:
● Уровень доступности
В SLA облачного провайдера должны быть определены ключевые метрики,
описывающие работоспособность облачного сервиса. Речь идет о доступности
сервиса, количестве пользователей, способных получать доступ к сервису
одновременно, а также времени, необходимом для обработки транзакций
пользователей.
Также следует обозначить временные рамки, в которые этот уровень
доступности обеспечивается, чтобы у клиентов не возникало вопросов.
● Исключения
В SLA необходимо прописать допустимые условия, при которых провайдер не
гарантирует указанные доступность и производительность. Поскольку этот
раздел освобождает поставщика от выполнения своих обязанностей, список
ограничений должен быть строгим и коротким.
Также в SLA следует отметить гарантии доступности интерфейса управления
виртуальной инфраструктурой. Это позволит избежать недопонимания и других
инцидентов в случае, когда клиенту потребовалось экстренно увеличить
потребляемые мощности, а консоль самообслуживания оказалась недоступной.
● Мониторинг
Необходимо прописать в соглашении все, что касается безопасности и
надежности хранения данных. Речь идет о достоверности и
конфиденциальности информации, а также сохранности данных. Также нужно
определить права доступа к информации, и круг лиц, несущих ответственность
в случае ее повреждения.
Здесь же предоставляется информация об инструментах восстановления после
аварии, а также оговаривается процедура сообщения о сбоях и выходе
оборудования строя: формат и временные рамки и меры для восстановления
функционирования систем.
● Компенсации
Провайдер должен определить спектр компенсаций, которые он выплачивает в
случае нарушения показателей доступности и других параметров качества.
Ответственность провайдеры должна быть установлена в размере не менее,
чем 100% оплаты за отчетный период при длительном простое.
● Расчеты
Многие клиенты сталкиваются с вопросом корректного выполнения расчетов.
Чтобы клиент был спокоен и понимал, «что его ждет», то его расчеты не
должны расходиться со значениями, предлагаемыми поставщиком. Хорошим
вариантом будет использование детальных формул. Также рекомендуется
приводить наглядные расчетные примеры. Это поможет ИТ-отделу компании-
 клиента установить объемы необходимого аппаратного обеспечения и
мощностей, а также определиться с ПО для организации.
Важно помнить, что соглашения об уровне обслуживания для облачных услуг
отличаются от остальных SLA. Недобросовестные поставщики иной раз
предпочитают выстраивать отношения по принципу «одно ко многим»,
подразумевая использование единого SLA и предлагая его всем заказчикам.
Такой подход хорош для поставщиков, но совершенно не годится для клиентов
со специфическими задачами.
БИЗНЕС-СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ:
● СЦЕНАРИЙ ПЕРВЫЙ: ХРАНИЛИЩЕ РЕЗЕРВНЫХ КОПИЙ
Это самый простой вариант, который приходит в голову – вынести в облако
хранилище резервных копий данных. Эксперты в области бэкапа советуют
хранить копии критически важных данных на удаленной площадке. А еще
лучше – организовать облачное хранилище, развернутое в европейском дата-
центре, куда информация передается по защищенным каналам с
использованием криптографических протоколов, а данные на дисках защищены
средствами аппаратного шифрования. При необходимости можно договориться
с провайдером и восстановить данные из резервных копий на удаленной
площадке, тем самым организовав “клон” вашей корпоративной
инфраструктуры.
● СЦЕНАРИЙ ВТОРОЙ: РЕЗЕРВНАЯ ПЛОЩАДКА
Организовать отказоустойчивую инфраструктуру локально – дело слишком
затратное и по времени, и по средствам. Есть выход – вместо того, чтобы
строить свой собственный кластер (фактически это будет локальный дата-
центр), воспользуйтесь облаком для организации резервной площадки. Этим
вариантом пользуются не только компании сектора СМБ, но и крупные
корпорации.
● СЦЕНАРИЙ ТРЕТИЙ: ПЛОЩАДКА ДЛЯ ПИКОВЫХ НАГРУЗОК
Если у вашего бизнеса ярко выраженная сезонность, либо характерно
чередование периодов повышенной нагрузки и рутины, в облако можно
вынести именно те приложения, которые используются в высоконагруженный
период. Многочисленные инструменты интеграции локальных и облачных
приложений на рынке обеспечат эффективную работу такой инфраструктуры.
● СЦЕНАРИЙ ЧЕТВЕРТЫЙ: СРЕДА РАЗВЕРТЫВАНИЯ ДЛЯ ВОСТРЕБОВАННЫХ
ПРОЕКТОВ
В компаниях с разветвленной оргструктурой разработкой проектов под
потребности бизнеса занимаются отдельные команды. Аудит ресурсов перед
началом проекта должен учитывать буквально всё, до мелочей, включая и
ресурсы для развертывания продукта. В сферическом IT в вакууме так и
делается, но в нашей реальности – не всегда. Поэтому если подразделение-
заказчик ждет приложение, а локальных вычислительных ресурсов для него не
хватит, на помощь придет облако. Возможно, благодаря такому решению ваш
финальный продукт даже превзойдет ожидания.
● СЦЕНАРИЙ ПЯТЫЙ: МИГРАЦИЯ В ОБЛАКО ВСЕЙ ИНФРАСТРУКТУРЫ И
ОТКАЗ ОТ ЛОКАЛЬНОГО “ЖЕЛЕЗА”
Это классический вариант, который обычно рассматривают. Он позволяет в
полной мере испытать все преимущества облачных технологий, о которых мы
уже говорили. Провайдер, как правило, берет на себя заботу о миграции систем
 клиента и старается организовать работы по переезду так, чтобы
минимизировать влияние на бизнес.

Модели облачных сервисов.

IaaS (Infrastructure as a Service-Инфраструктура как Услуга)
Данная услуга является одной из самых распространенных в мире. Заключается она в
предоставлении заказчику в аренду вычислительных ресурсов, в виде виртуальной
инфраструктуры. В нее могут входить серверы, системы хранения данных,
виртуальные коммутаторы и маршрутизаторы. Такая ИТ-инфраструктура является
полноценной копией физической среды.
PaaS (Platform as a Service-Платформа как Услуга)
Эта услуга также является одной из основных. Она состоит в том, что заказчик
получает полноценную виртуальную платформу, включающую в себя различные
инструменты и сервисы. Такую платформу клиент может настроить под свои нужды,
сделав из нее площадку для тестирования ПО или, например, систему для
автоматизации системы управления. Такой вид сервиса пользуется особой
популярностью у разработчиков программного обеспечения.
SaaS (Software as a Service-Программное обеспечение как Услуга)
Данная облачная услуга на данный момент считается самой распространенной в
мире, так как пользуются ей практически все люди имеющие доступ в интернет.
Заключается такая услуга в том, что клиент получает в свое распоряжение какие либо
программные продукты посредством сети интернет. В качестве примера можно
привести почтовый сервис Gmail, или, например, облачную версию 1С.
CaaS (Communications as a Service-Коммуникация как Услуга)
Данная услуга заключается в предоставлении клиентам различных инструментов
коммуникации в облаке. Это может быть телефония, сервисы по передаче быстрых
сообщений или организации видеосвязи. При этом все необходимое ПО расположено
в облаке провайдера.
CaaS (Container as a Service-Контейнер как Услуга)
Данная услуга позволяет клиентам работать с контейнерами с помощью API
облачного провайдера или специальной веб-панели.
DRaaS (Disaster Recovery as a Service-Аварийное Восстановление как Услуга)
Данная услуга позволяет строить катастрофоустойчивые решения с помощью облака
провайдера. Площадка поставщика облачных услуг является при этом «запасным
аэродромом», на который постоянно реплицируются данные с основной площадки
клиента. При выходе из строя сервисов клиента, они в течении нескольких минут
перезапускаются, но уже в облаке. Такие решения особенно интересны компаниям с
большим количеством бизнес-критичных приложений.
BaaS (Backup as a Service-Резервное Копирование как Услуга)
Этот вид услуги подразумевает обеспечение резервного копирования данных клиента
в облако провайдера. Поставщик облачных услуг предоставляет заказчику не только
место для хранения резервных копий, но, также, и инструменты позволяющие
обеспечить быстрое и надежное копирование. Для правильной реализации данной
услуги очень важен этап планирования, в период которого должны быть рассчитаны
параметры и глубина архива, а также пропускная способность каналов передачи
данных.
BaaS (Backend as a Service-Бэкенд как услуга)
Данная облачная услуга заключается в предоставлении заказчику полноценной среды
разработки программного обеспечения в облаке провайдера. Данная модель включает
в себя уже готовые инфраструктурные функции и решения, значительно упрощая
работу разработчиков ПО

Модель IaaS. Охарактеризуйте её.

Инфраструктура как услуга (IaaS, англ. Infrastructure-as-a-Service) предоставляется
как возможность использования облачной инфраструктуры для самостоятельного
управления ресурсами обработки, хранения, сетями и другими фундаментальными
вычислительными ресурсами, например, потребитель может устанавливать и
запускать произвольное программное обеспечение, которое может включать в себя
операционные системы, платформенное и прикладное программное обеспечение.
Потребитель может контролировать операционные системы, виртуальные системы
хранения данных и установленные приложения, а также обладать ограниченным
контролем за набором доступных сетевых сервисов (например, межсетевым экраном,
DNS). Контроль и управление основной физической и виртуальной инфраструктурой
облака, в том числе сети, серверов, типов используемых операционных систем,
систем хранения осуществляется облачным провайдером.
Принцип работы IaaS
При аренде виртуальной инфраструктуры у IaaS-провайдера, вы можете
воспользоваться услугами разного масштаба: виртуальный сервер (VPS/VDS) и
виртуальная сеть.
В первом случае вы арендуете единственный виртуальный сервер, во втором — пул
виртуальных серверов с возможностью их объединения в виртуальную сеть.Вы
получаете полные административные права внутри арендованных виртуальных
серверов. Все настройки операционных систем этих серверов вам нужно выполнять
самостоятельно: устанавливать программное обеспечение, конфигурировать
брандмауэр и т. д. Конечно, служба поддержки IaaS-провайдера может оказать вам
консультацию по вопросу, вызвавшему затруднение. Некоторые сервисы даже
возьмутся сделать часть работ по настройке серверов за вас. Но уже за отдельную
плату, так как подобные услуги не входят в модель IaaS. Изначально, провайдер лишь
гарантирует, что ваш сервер будет доступен по сети в соответствии с соглашением об
уровне услуг (SLA).
Основными задачами IaaS-провайдера являются установка и обеспечение
работоспособности оборудования и базового инфраструктурного программного
обеспечения. «Железо», на котором построена виртуальная инфраструктура,
находится в специализированных центрах обработки данных (ЦОД). в этих центрах
обеспечивается резервирование каналов связи, защита от перебоев с электричеством
и многое другое. в результате, всё, что непосредственно связано с
работоспособностью и доступностью оборудования, вас не будет больше беспокоит.
Эти заботы будут лежать на плечах работников провайдера, для которых
администрирование оборудования является профильной деятельностью.
Важнейшие преимущества
● Унифицированная система управления. В случае IaaS вместо множества
систем, требующих мониторинга и контроля, имеется единственный интерфейс
 управления. В результате повышаются эффективность и надежность частных и
публичных облачных сред.
● Сервисы по запросу. Потребности компаний в ИТ обычно бывают непостоянны
и зависят от эффективности их деятельности в тот или иной момент.
Например, при значительном росте бизнеса может возрасти и потребность в
сервисах.
● Взаимная совместимость. Традиционные ИТ-поставщики обычно используют
патентованные системы, поэтому при смене провайдера могут возникать
трудности. IaaS же поддерживает любое количество платформ, будь они
виртуальными, физическими или облачными.
Использование IaaS ослабляет зависимость от конкретного производителя и
уменьшает связанные с этим сложности. А у предприятий отпадает необходимость
создавать у себя новую инфраструктуру, обеспечивать ее защиту и налаживать
управление, так что они могут сосредоточиться на инновациях.
Модели развертывания IaaS:
● Частное облако (англ. private cloud) — инфраструктура, предназначенная для
использования одной организацией, включающей несколько потребителей
(например, подразделений одной организации), возможно также клиентами и
подрядчиками данной организации. Частное облако может находиться в
собственности, управлении и эксплуатации как самой организации, так и
третьей стороны (или какой-либо их комбинации), и оно может физически
существовать как внутри, так и вне юрисдикции владельца.
● Публичное облако (англ. public cloud) — инфраструктура, предназначенная для
свободного использования широкой публикой. Публичное облако может
находиться в собственности, управлении и эксплуатации коммерческих,
научных и правительственных организаций (или какой-либо их комбинации).
Публичное облако физически существует в юрисдикции владельца —
поставщика услуг.
● Общественное облако (англ. community cloud) — вид инфраструктуры,
предназначенный для использования конкретным сообществом потребителей
из организаций, имеющих общие задачи (например, миссии, требований
безопасности, политики, и соответствия различным требованиям).
Общественное облако может находиться в кооперативной (совместной)
собственности, управлении и эксплуатации одной или более из организаций
сообщества или третьей стороны (или какой-либо их комбинации), и оно может
физически существовать как внутри, так и вне юрисдикции владельца.
● Гибридное облако (англ. hybrid cloud) — это комбинация из двух или более
различных облачных инфраструктур (частных, публичных или общественных),
остающихся уникальными объектами, но связанных между собой
стандартизованными или частными технологиями передачи данных и
приложений (например, кратковременное использование ресурсов публичных
облаков для балансировки нагрузки между облаками).
Модель PaaS. Охарактеризуйте её.
(PaaS) — это полноценная среда разработки и развертывания в облаке с ресурсами,
которые позволяют предоставлять любые приложения, от простых облачных
приложений до продвинутых облачных приложений промышленного класса.
Основные функции:
● PaaS предоставляет платформу с инструментами для тестирования,
разработки и размещения приложений в той же среде.
● Организации получают возможность сосредоточиться на разработке, не
беспокоясь о базовой инфраструктуре.
● Поставщики управляют защитой, операционными системами, серверным
программным обеспечением и резервным копированием.
● Облегчается совместная работа, даже если сотрудники работают удаленно
PaaS включает инфраструктуру (серверы, хранилище и сетевое оборудование), а
также ПО промежуточного слоя, средства разработки, бизнес-аналитику (BI), службы
системы управления базами данных и другое. Услуга PaaS предназначена для
поддержки полного жизненного цикла веб-приложения: разработки, тестирования,
развертывания, управления и обновления.
PaaS имеет некоторое сходство с IaaS, однако клиенты PaaS-провайдера могут
пользоваться средой, приложениями, но не имеют возможности масштабировать
инфраструктуру. То есть отключить неиспользуемые мощности или изменить
конфигурацию инстансов (как это делается в SIM-Cloud Dashboard, например),
пользователь не может. Разница между услугами IaaS и PaaS состоит в том, что в
рамках модели «платформа-как-сервис» вы получаете вычислительную платформу и
стек решений, но никак не влияете на конфигурацию виртуальной инфраструктуры.
Модель PaaS предоставляет «песочницу» и среду развертывания с
предустановленными настройками, которая позволяет пользователям разрабатывать,
тестировать и развертывать свои приложения. При этом грамотная стратегия
использования API делает работу с PaaS максимально эффективной.
Примеры PaaS-решений: Google App Engine, VMWare Cloud Foundry, IBM Bluemix и др.
Преимущества PaaS
Предоставляя инфраструктуру как услугу, PaaS предлагает те же преимущества, что и
IaaS. Однако дополнительные компоненты (ПО промежуточного слоя, средства
разработки и другие бизнес-средства) создают следующие дополнительные
преимущества:
● Сокращение времени программирования. Средства разработки PaaS могут
сократить время, необходимое для программирования новых приложений
благодаря заранее подготовленным компонентам, встроенным в платформу,
Добавление возможностей разработки без увеличения числа сотрудников.
Компоненты платформы как услуги предоставляют новые возможности без
необходимости нанимать сотрудников с соответствующими навыками.
● Упрощенная разработка для нескольких платформ, включая мобильные
платформы.
● Экономичное использование продвинутых средств. Оплата по мере
использования позволяет физическим и юридическим лицам использовать
продвинутые средства разработки и бизнес-аналитики, которые могут быть
слишком дорогими для приобретения в собственность.
 ● Поддержка географически распределенных команд разработчиков. Поскольку
доступ к среде разработки осуществляется через Интернет, команда
разработчиков может работать над одними проектами, даже когда члены
команды находятся в разных местах.
● Эффективное управление жизненным циклом приложений. PaaS обеспечивает
все возможности, которые потребуются для поддержки полноценного
жизненного цикла веб-приложений: создания, тестирования, развертывания,
управления и обновления внутри одной интегрированной среды.

Модель SaaS. Охарактеризуйте её.

SaaS (англ. Software-as-a-Service - программное обеспечение как услуга, или также
англ. software on demand - программное обеспечение по требованию) - является
лицензией на программное обеспечение и моделью поставки, в которой программное
обеспечение лицензируется на основе подписки и размещается централизованно.
Ранее Microsoft называла это "ПО плюс услуги". SaaS обычно доступен
пользователям, использующим тонкий клиент через веб-браузер. SaaS стала общей
моделью поставки для многих бизнес-приложений, включая ПО для офиса и обмена
сообщениями, программное обеспечение для обработки платежных ведомостей, ПО
для СУБД, программное обеспечение для менеджмента, программное обеспечение
САПР, программное обеспечение для разработки, виртуализацию, учет,
сотрудничество и управление отношениями с клиентами (CRM), информационные
системы управления (MIS), планирование ресурсов предприятия (ERP), выставление
счетов, управление человеческими ресурсами (HRM), управление контентом (CM) и
управление службами поддержки. SaaS был включен в стратегию почти всех ведущих
компаний программного обеспечения для предприятий. Потребителем SaaS является
конечный пользователь. В зону ответственности поставщика услуг SaaS входит
поддержание доступности и работоспособности поставляемых приложений,
предоставляя при этом минимальный набор изменяемых параметров.
Требования:
● Инфраструктура: Для SaaS на стороне клиента необходимы лишь рабочие
места - компьютеры и канал связи с облачным провайдером.
● Человеческие ресурсы: Для потребления услуг SaaS на стороне клиента нет
необходимости в содержании технического специалиста. Для стабильной
работы будет достаточно менеджера с минимальными ИТ - навыками лишь для
поддержания контакта с поставщиком услуг SaaS
Архитектура
Подавляющее большинство решений SaaS основаны на многопользовательской
архитектуре. С этой моделью для всех клиентов («арендаторов») используется одна
версия приложения с единой конфигурацией (аппаратное обеспечение, сеть,
операционная система). Для поддержки масштабируемости приложение
устанавливается на нескольких машинах (называемое горизонтальным
масштабированием). В некоторых случаях вторая версия приложения настроена так,
чтобы предлагать избранную группу клиентов, имеющих доступ к предварительно
выпущенным версиям приложений (например, бета-версии) для целей тестирования.
Это контрастирует с традиционным программным обеспечением, где на разных сайтах
клиентов устанавливаются несколько физических копий программного обеспечения -
каждая потенциально из другой версии с потенциально различной конфигурацией и
часто настраивается - устанавливаются на разных сайтах клиентов. В этой
традиционной модели каждая версия приложения основана на уникальном коде.
Несмотря на исключение, а не на норму, некоторые решения SaaS не используют
многопользовательскую работу или используют другие механизмы, такие как
виртуализация, чтобы экономически эффективно управлять большим количеством
клиентов вместо многоуровневости.
Существует два основных типа SaaS:
1. Вертикальные SaaS - Программное обеспечение, отвечающее потребностям
конкретной отрасли (например, программное обеспечение для
здравоохранения, сельского хозяйства, недвижимости, финансовых отраслей)
2. Горизонтальные SaaS - Продукты, которые ориентированы на категорию
программного обеспечения (маркетинг, продажи, инструменты для
разработчиков, HR), но являются агностиками отрасли.
Характеристики
Конфигурация и настройка
Приложения SaaS также поддерживают то, что традиционно называют настройкой
приложения. Другими словами, как и традиционное корпоративное программное
обеспечение, один клиент может изменить набор параметров конфигурации
(параметров), которые влияют на его функциональность и внешний вид. У каждого
клиента могут быть свои собственные настройки (или: значения параметров) для
параметров конфигурации. Приложение может быть настроено в той степени, в
которой оно было разработано на основе набора предопределенных параметров
конфигурации.
Например: чтобы поддерживать общую потребность клиентов в изменении внешнего
вида приложения, чтобы приложение имело бренд клиента многие приложения SaaS
позволяют клиентам предоставлять (через Интерфейс самообслуживания или работая
с персоналом провайдера), пользовательский логотип. Однако заказчик не может
изменить макет страницы, если такой вариант не был разработан.
Преимущества частых обновлений
Приложения SaaS обновляются чаще, чем традиционное программное обеспечение,
во многих случаях еженедельно или ежемесячно. Это обеспечивается несколькими
факторами:
● Приложение размещается централизованно, поэтому обновление
определяется и выполняется поставщиком, а не клиентами.
● Приложение имеет только одну конфигурацию, что ускоряет тестирование
разработки.
● Поставщику приложения не нужно тратить ресурсы на обновление и поддержку
backdated версий программного обеспечения, потому что существует только
одна версия.
● Поставщик приложения имеет доступ ко всем данным о клиентах, ускоряя
проектирование и регрессионное тестирование.
● Поставщик решений имеет доступ к поведению пользователя в приложении
(обычно через веб-аналитику), что упрощает определение областей,
требующих улучшения.
Ускоренная доставка функций также обеспечивается гибкими методологиями
разработки программного обеспечения.
Открытые протоколы интеграции
Поскольку приложения SaaS не могут получить доступ к внутренним системам (базам
данных или внутренним службам) компании, они преимущественно предлагают
интеграционные протоколы и API, которые работают по глобальной сети. Как правило,
это протоколы на основе HTTP, REST и SOAP.
Вездесущность приложений SaaS и других интернет-сервисов и стандартизация их
технологий API породили разработку гибридных приложений, которые представляют
собой легкие приложения, которые объединяют данные, презентацию и
функциональность из нескольких сервисов, создавая сложную службу.
Совместная (и «социальная») функциональность
Вдохновляясь успехом онлайн-социальных сетей и других так называемых
функциональных возможностей Web 2.0, многие приложения SaaS предлагают
функции, позволяющие своим пользователям взаимодействовать и обмениваться
информацией.
Например, многие приложения для управления проектами, поставляемые в модели
SaaS, помимо традиционных функций планирования проектов - функции совместной
работы, позволяющие пользователям комментировать задачи и планы и
обмениваться документами внутри и вне организации. Некоторые другие SaaS-
приложения позволяют пользователям голосовать и предлагать новые функции.
Хотя некоторые функциональные возможности, связанные с сотрудничеством, также
интегрированы в локальное программное обеспечение, (неявное или явное)
сотрудничество между пользователями или разными клиентами возможно только при
использовании централизованно размещенного программного обеспечения.
Положительные факторы роста популярности SaaS:
● Растущее использование прикладных интерфейсов на основе веб-приложений,
а также распространение связанных с ними практик (например, веб-дизайн)
постоянно уменьшали потребность в традиционных клиент-серверных
приложениях. Следовательно, инвестиции традиционного поставщика
программного обеспечения в программное обеспечение, основанное на
толстых клиентах, стали недостатком (обязательным условием постоянной
поддержки), открывая двери для новых поставщиков ПО, предлагающих
пользователям более «современные» решения.
● Стандартизация технологий веб-страниц (HTML, JavaScript, CSS), рост
популярности веб-разработки как практики, а также внедрение и
повсеместность таких веб-приложений, как Ruby on Rails или Laravel (PHP),
постепенно снизили стоимость разработки новых SaaS Решений и позволило
новым поставщикам решений выработать конкурентные решения, бросая вызов
традиционным поставщикам.
● Увеличение проникновения широкополосного доступа в Интернет позволило
удаленным централизованно размещенным приложениям предлагать скорость,
сопоставимую с внутренним программным обеспечением.
● Стандартизация протокола HTTPS как части веб-стека обеспечивала
универсальную легкую безопасность, достаточную для большинства
повседневных приложений.
● Внедрение и широкое принятие легких интеграционных протоколов, таких как
REST и SOAP, позволило обеспечить доступную интеграцию между
приложениями SaaS (находящимися в облаке) с помощью внутренних
приложений в глобальных сетях и с другими приложениями SaaS.
Ограничение SaaS
Некоторые ограничения замедляют развитие SaaS и запрещают его использование в
некоторых случаях:
● Поскольку данные хранятся на серверах поставщика, основной проблемой
становится безопасность данных.
● Приложения SaaS размещаются в облаке, вдали от пользователей
приложения. Это вводит задержку в работу сервисов; Так, например, модель
SaaS не подходит для приложений, которые требуют времени ответа в
миллисекундах.
● Многоуровневые архитектуры, которые обеспечивают экономическую
эффективность для поставщиков решений SaaS, ограничивают настройку
приложений для крупных клиентов, препятствуя использованию таких
приложений в сценариях (применимых главным образом к крупным
предприятиям), для которых такая настройка необходима.
● Некоторые бизнес-приложения требуют доступа или интеграции с текущими
данными клиента. Когда такие данные являются большими по объему или
чувствительны (например, личная информация конечных пользователей), их
интеграция с удаленно размещенным программным обеспечением может быть
дорогостоящей и рискованной или может противоречить правилам управления
данными.
● Смена поставщиков SaaS может включать медленную и сложную задачу
передачи очень больших файлов данных через Интернет.
● Организации, которые используют SaaS, могут обнаружить, что они вынуждены
использовать новые версии, что может привести к непредвиденным затратам
на обучение, увеличению вероятности того, что пользователь может сделать
ошибку, или нестабильности от ошибок в более новом программном
обеспечении.
● Если поставщик программного обеспечения закрывает свой бизнес,
пользователь может неожиданно потерять доступ к своему программному
обеспечению, что может дестабилизировать текущие и будущие проекты его
организации, а также оставить пользователю более старые данные.
● Опора на подключение к Интернету означает, что данные передаются в и из
SaaS-фирмы на скорости интернета, а не потенциально более высокие
скорости внутренней сети фирмы.
Преимущества SaaS:
● Для предоставления приложения SaaS пользователям, нет необходимости
приобретать, устанавливать, обновлять и обслуживать оборудование, ПО
промежуточного слоя или программное обеспечение. Если у организаций нет
ресурсов для приобретения, развертывания необходимой инфраструктуры и
программного обеспечения таких сложных промышленных приложений, как
ERP или CRM, а также для управления ими, то можно сделать их доступными
через SaaS.
● Оплачиваются только те ресурсы, которые используются. SaaS автоматически
изменяет масштабирование в соответствии с уровнем использования.
● Пользователи могут запускать большинство приложений SaaS напрямую через
веб-браузер без необходимости загружать и устанавливать программное
обеспечение, хотя для некоторых приложений требуются подключаемые
модули. Это означает, что нет необходимости приобретать и устанавливать
специальное программное обеспечение для пользователей.
 ● SaaS повышает мобильность сотрудников, так как пользователи имеют доступ к
приложениям и данным SaaS с любого компьютера или мобильного устройства,
которые подключены к Интернету. Кроме того, нет необходимости нанимать
квалифицированных специалистов для решения проблем с безопасностью,
которые могут возникнуть при использовании мобильных устройств.
● Доступ к данным приложений из любого места. Когда данные хранятся в
облаке, пользователи получают доступ к нужной информации с любого
компьютера или мобильного устройства, подключенных к Интернету. Данные не
могут быть потеряны в результате сбоя компьютера или устройства

IoT или интернет вещей.

Интернет вещей (англ. internet of things, IoT) — концепция сети передачи данных
между физическими объектами («вещами»), оснащенными встроенными средствами и
технологиями для взаимодействия друг с другом или с внешней средой
Интернет вещей (IoT) - это об огромном количестве «вещей», которые подключены к
Интернету для обмена данными с другими вещами - приложениями IoT,
подключенными устройствами, промышленными машинами и многим другим.
Устройства, подключенные к Интернету, используют встроенные датчики для сбора
данных и, в некоторых случаях, воздействуют на них. Подключенные к IoT устройства
и машины могут улучшить нашу работу и жизнь.
Ключевые особенности IoT:
● Управление данными и потоковая аналитика. Интернет вещей предъявляет
высокие требования к управлению данными для потоковой передачи больших
данных с датчиков. Технология обработки потока событий, часто называемая
потоковой аналитикой, выполняет управление данными в реальном времени и
аналитику данных IoT, чтобы сделать их более ценными. Ключевые
возможности включают фильтрацию, нормализацию, стандартизацию,
преобразование, агрегирование, корреляцию и временной анализ.
● Аналитика больших данных. IoT является основным источником больших
данных - огромный объем, скорость и разнообразие структурированных и
неструктурированных данных, которые предприятия собирают каждый день.
Чтобы получить выгоду от больших данных в IoT, требуется анализ больших
данных. Связанные методы включают в себя интеллектуальную аналитику,
анализ текста, облачные вычисления, анализ данных, озер данных и Hadoop.
Большинство организаций используют комбинацию этих методов для
получения максимальной отдачи от Интернета вещей.
● Искусственный интеллект. Искусственный интеллект может увеличить
ценность IoT, используя все данные с умных устройств для развития обучения
и коллективного интеллекта. Некоторые из основных методов, которые
использует ИИ, - это машинное обучение, глубокое обучение, обработка
естественного языка и компьютерное зрение.
Многие отрасли используют IoT для понимания потребностей потребителей в режиме
реального времени, повышения оперативности, мгновенного улучшения качества
машин и систем, оптимизации операций и поиска инновационных способов работы в
рамках своих усилий по цифровому преобразованию.
Производство
IoT объединяет все этапы процесса промышленного Интернета вещей (IIoT) - от
цепочки поставок до доставки - для согласованного представления данных о
производстве, процессе и продукте. Усовершенствованные датчики IoT на заводских
станках или на складах, а также аналитика больших данных и прогнозное
моделирование могут предотвратить дефекты и простои, максимально повысить
производительность оборудования, сократить гарантийные расходы, повысить
производительность и повысить качество обслуживания клиентов.
Здравоохранение
Технология IoT обеспечивает потоковую передачу данных в режиме реального
времени из Интернета медицинских вещей (IoMT), таких как носимые и другие
медицинские устройства, которые отслеживают физические упражнения, сон и другие
привычки. Эти данные IoT позволяют проводить точную диагностику и составлять
планы лечения, повышать безопасность пациентов и результаты и оптимизировать
оказание медицинской помощи.
Энергия
Интернет вещей помогает провайдерам предоставлять надежные, доступные по цене
услуги и продукты. Подключенные к IoT устройства и машины прогнозируют проблемы
до их возникновения. Распределенные сетевые ресурсы, такие как солнечная энергия
и энергия ветра, интегрированы через Интернет вещей. А данные о поведении,
например, полученные из умных домов, повышают удобство и безопасность, а также
помогают разрабатывать индивидуальные услуги.
Интернет вещей в b2c:
● носимые устройства
● умный дом (smart home)
● умная одежда
● smart TV
● умные девайсы для животных
● другое
Интернет вещей в b2b:
● умный транспорт (connected cars) и беспилотники
● умный город (smart city)
● страховая телематика (usage-based insurance)
● умные рабочие места
● умные электросети (smart grid)
● умные заводы (smart factory, industrial internet, IIoT)
● точное земледелие
● умные скважины smart well
● геолокационный маркетинг, в том числе биконы
● умные склады
● другое

Сферы применения Больших Данных.

Большие Данные, на сегодняшний момент, являются одним из ключевых драйверов
развития информационных технологий. Это направление, относительно новое для
российского бизнеса, получило широкое распространение в западных странах.
Связано это с тем, что в эпоху информационных технологий, особенно после бума
социальных сетей, по каждому пользователю интернета стало накапливаться
значительное количество информации, что в конечном счете дало развитие
направлению Big Data.
Термин «Большие Данные» вызывает множество споров, многие полагают, что он
означает лишь объем накопленной информации, но не стоит забывать и о технической
стороне, данное направление включает в себя технологии хранения, вычисления, а
также сервисные услуги.
Следует отметить, что к данной сфере относится обработка именно большого объема
информации, который затруднительно обрабатывать традиционными способами.
Сфера Больших Данных характеризуется следующими признаками:
● Volume – объем, накопленная база данных представляет собой большой объем
информации, который трудоемко обрабатывать и хранить традиционными
способами, для них требуются новый подход и усовершенствованные
инструменты.
● Velocity – скорость, данный признак указывает как на увеличивающуюся
скорость накопления данных (90% информации было собрано за последние 2
года), так и на скорость обработки данных, в последнее время стали более
востребованы технологии обработки данных в реальном времени.
● Variety – многообразие, т.е. возможность одновременной обработки
структурированной и неструктурированной разноформатной информации.
Главное отличие структурированной информации – это то, что она может быть
классифицирована. Примером такой информации может служить информация
о клиентских транзакциях. Неструктурированная информация включает в себя
видео, аудио файлы, свободный текст, информацию, поступающую из
социальных сетей. На сегодняшний день 80% информации входит в группу
неструктурированной. Данная информация нуждается в комплексном анализе,
чтобы сделать ее полезной для дальнейшей обработки.
● Veracity – достоверность данных, все большее значение пользователи стали
придавать значимость достоверности имеющихся данных. Так, у интернет-
компаний есть проблема по разделению действий, проводимых роботом и
человеком на сайте компании, что приводит в конечном счете к затруднению
анализа данных.
● Value – ценность накопленной информации. Большие Данные должны быть
полезны компании и приносить определенную ценность для нее. К примеру,
помогать в усовершенствовании бизнес-процессов, составлении отчетности
или оптимизации расходов.
При соблюдении указанных выше 5 условий, накопленные объемы данных можно
относить к числу больших.
Сферы применения Больших Данных
Сфера использования технологий Больших Данных обширна. Так, с помощью
Больших Данных можно узнать о предпочтениях клиентов, об эффективности
маркетинговых кампаний или провести анализ рисков.
Большинство компаний используют Большие Данные в сфере клиентского сервиса,
второе по популярности направление – операционная эффективность, в сфере
управления рисками Большие Данные менее распространены на текущий момент.
Большие Данные получили широкое распространение во многих отраслях бизнеса. Их
используют в здравоохранении, телекоммуникациях, торговле, логистике, в
финансовых компаниях, а также в государственном управлении.
Примеры применения Больших Данных в некоторых из отраслей:
● Розничная торговля
В базах данных розничных магазинов может быть накоплено множество
информации о клиентах, системе управления запасами, поставками товарной
продукции. Данная информация может быть полезна во всех сферах
деятельности магазинов.
Так, с помощью накопленной информации можно управлять поставками товара,
его хранением и продажей. На основании накопленной информации можно
прогнозировать спрос и поставки товара. Также система обработки и анализа
данных может решить и другие проблемы ритейлера, например,
оптимизировать затраты или подготовить отчетность.
● Финансовые услуги
Большие Данные дают возможность проанализировать кредитоспособность
заемщика, также они полезны для кредитного скоринга* и андеррайтинга**.
Внедрение технологий Больших Данных позволит сократить время
рассмотрения кредитных заявок. С помощью Больших Данных можно
проанализировать операции конкретного клиента и предложить подходящие
именно ему банковские услуги.
● Телеком
В телекоммуникационной отрасли широкое распространение Большие Данных
получили у сотовых операторов.
Операторы сотовой связи наравне с финансовыми организациями имеют одни
из самых объемных баз данных, что позволяет им проводить наиболее
глубокий анализ накопленной информации.
Главной целью анализа данных является удержание существующих клиентов и
привлечение новых. Для этого компании проводят сегментацию клиентов,
анализируют их трафики, определяют социальную принадлежность абонента.
Помимо использования Big Data в маркетинговых целях, технологии применяются для
предотвращения мошеннических финансовых операций.
● Горнодобывающая и нефтяная промышленности
Большие Данные используются как при добыче полезных ископаемых, так и при
их переработке и сбыте. Предприятия могут на основании поступившей
информации делать выводы об эффективности разработки месторождения,
отслеживать график капитального ремонта и состояния оборудования,
прогнозировать спрос на продукцию и цены.

Виды облаков. Платформенные сервисы.

Все виды облачных услуг можно разделить на три типа:
● Infrastructure as a Service (инфраструктура как услуга);
● Platform as a Service (платформа как услуга);
● Software as a Service (программное обеспечение как услуга).
Сегмент PaaS — самый узкий и специализированный среди трех основных типов
облачных сервисов (два других — это IaaS и SaaS
Platform as a Service («Платформа как услуга»), или сокращенно PaaS — это
специальная модель предоставления облачных сервисов, в рамках которой заказчик
получает в свое распоряжение также готовую программную среду, включающую
операционную систему, ПО промежуточного уровня (middleware), а также инструменты
для разработки и тестирования (framework). В ряде случаев к этому перечню
добавляется также система управления базами данных (СУБД). Вместе с тем клиенту
предлагаются и программные инструменты для детализированной настройки рабочей
среды.
Также платформенные сервисы могут включать средства разработки,
балансировщики нагрузки, среды запуска контейнеризованных приложений,
инструменты бизнес-аналитики и другое. С их помощью вы можете полноценно
разработать, протестировать и развернуть приложение, а затем обновлять его.
Высокая доступность, поддержка множества пользователей и масштабирование
платформенных сервисов повышает эффективность разработки. Кроме того, при
использовании у вас не будет проблем с лицензиями на необходимое ПО. . Все эти
вопросы уже решил облачный провайдер и ваша работа полностью легальна.
Средства разработки сократят время на запуск новых приложений, потому что
множество компонентов уже встроены в платформу. Некоторые провайдеры могут
дать вам среду разработки не для одной, а для множества платформ, например, для
мобильных и браузерных. Таким образом, процесс создания новых приложений станет
еще удобнее и быстрее. Примеры таких сервисов — IBM Bluemix, Heroku, Google App
Engine
Инструменты для подключения, интеграции и расширения приложений:
● Визуальные средства разработки
● Каталог API
● Возможность репликации баз данных
● Развитые инструменты администрирования
● Поддержка языков и платформ на основе открытого кода
● Широкая совместимость различных платформ разработки
● Готовые инструменты для переноса приложений в облако
● Поддержка технологий блокчейн
● Наличие инструментария бизнес-аналитики
● Интегрированные средства безопасности для облачных и гибридных
инфраструктур
Преимущества PaaS
К преимуществам PaaS относят:
● Предоставление единой среды для создания программных продуктов
● Доступ к среде разработки большого количества территориально удаленных
пользователей
● Встроенные функции обмена сообщениями, группового общения и
комментирования
● Детализированная отчетность по использованию программных и аппаратных
ресурсов
● Интеграция с сервисами IaaS
● Упрощение процесса администрирования
● Автоматическое обновление программного обеспечения до наиболее свежих
версий
● Сокращение времени на развертывание программных для разработки
● Гибкость использования ресурсов — отказаться от использования услуги можно
в любой момент
 ● Доступ к сервису обеспечивается по интернет-каналам, поэтому для клиентов
доступна максимальная мобильность
● Вся основная обработка данных происходит на стороне оператора, что
позволяет предъявлять пониженные требования к пользовательским
терминалам
● Защита данных в облаке, а также все вопросы, связанные с
кибербезопасностью обеспечиваются оператором
● Высокая отказоустойчивость сервиса
● Круглосуточная техническая поддержка
Недостатки
Выделяют следующие недостатки PaaS:
● PaaS обладает меньшей гибкостью и предоставляет меньшую степень
контроля над вычислительной инфраструктурой по сравнению с IaaS
● Скорость доступа к данным и приложениям будет относительно низкой,
особенно в сравнении с локальными системами
● Данные передаются по общедоступным каналам связи, что требует
повышенного внимания к вопросам информационной безопасности
● Привязка к конкретному оператору PaaS
● Ограничение функционала теми возможностями, которые дает оператор
сервиса

Типичная архитектура сайта.

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

Виртуальные машины. Примеры

далее.

использования.
Виртуальная машина – это точная копия обычного компьютера или сервера, с любой
желаемой ОС и набором установленных программ. Ее действительно нельзя
потрогать, но зато вполне реально ощутить. С ВМ (так сокращенно называют
виртуальную машину) можно работать также, как с физическим сервером или
стационарным компьютером. Для этого достаточно выполнить подключение, причем
для доступа к ВМ используются специальные службы, либо консоль, которую
предоставляет провайдер облачных услуг. Главное, иметь выход в сеть и учетную
запись с соответствующими полномочиями.
С другой стороны, виртуальная машина – это программа, которая эмулирует реально
существующий компьютер или сервер, и запускается в отдельном окне. Она состоит
из виртуального жесткого диска, процессора, памяти, сетевой и видеокарты,
контроллеров устройств и прочих элементов. Прелесть виртуализированного подхода
заключается в возможности контролировать ресурсы машины самостоятельно: вы
можете увеличивать или уменьшать используемые ресурсы по требованию, причем
делать это за считанные секунды.
Как и любая другая программа, виртуальная машина состоит из набора файлов,
которые хранятся на дисках физического сервера, внутри файловой системы
гипервизора. На сегодняшний день существует несколько вариантов гипервизоров,
представленных различными игроками рынка (VMware, Microsoft, Citrix и пр.). Поэтому
у каждого продукта набор и формат файлов отличаются друг от друга. Например,
виртуальная машина может быть представлена в виде файла с расширением .vmdk
или .vhdx. и хранить в себе ОС, драйвера, связанные данные.
Если проиллюстрировать разницу между обычным сервером и виртуальной машиной,
она будет выглядеть так, как показано на картинке. В первом случае, когда мы говорим
о физическом сервере, ОС инсталлируется на железо, используя предустановленные
физические компоненты, во втором случае на сервере установлен гипервизор –
специальная технология, которая создает соответствующую среду для развертывания
в ней виртуальных машин. Обратите внимание, что на одном таком сервере может
быть развернуто множество виртуальных машин, изолированных и независимых друг
от друга. Каждая такая ВМ потребляет столько виртуальных ресурсов (RAM, CPU,
процессор), сколько было задано при ее создании или последующей конфигурации.
Преимущества виртуальных машин:
● Быстрый запуск — Одно из преимуществ виртуальных машин заключается в
высокой скорости развертывания. В отличие от привычного оборудования,
которое еще нужно купить и доставить до места назначения, ВМ позволяет
отойти от этих проблем и больше сконцентрироваться на решении конкретной
задачи.
● Гибкость переноса данных — Если вам нужно перенести данные или
приложения, лучший способ сделать это – воспользоваться виртуальной
машиной. Достаточно мигрировать ВМ с одной локации на другую и вместе с
ней перенесется все содержимое.
● Установка различных ОС — На виртуальную машину можно устанавливать
практически любые ОС, что особенно актуально для разработчиков ПО.
● Мобильность рабочих нагрузок — Поскольку вычислительные ресурсы ВМ не
зависят от базового оборудования, это позволяет перемещать виртуальные
машины между физическими системами. Единственным требованием к
миграции являются совместимый гипервизор и достаточное количество
вычислительных ресурсов на конечном сервере.
● Легкость дублирования — Поскольку содержимое виртуальной машины
инкапсулируется в файл на диске, его можно с легкостью дублировать. Это
позволяет в короткие сроки развернуть нужное количество ВМ с идентичными
характеристиками.
Примеры использования виртуальных машин
По статистике, виртуальные машины часто используются для тестирования. Допустим
разработчику нужно узнать корректно и безопасно ли работает приложение в другой
ОС, например, в разных версиях Windows. Покупать или арендовать для этого
несколько физических серверов, устанавливать разные ОС, чтобы выполнить
проверку – не самый лучший способ. Гораздо проще создать несколько виртуальных
машин и выполнить аналогичные действия за гораздо меньшее время.
Еще один частый пример с использованием ВМ – тестирование и анализ вредоносных
программ. Делать аналогичную проверку на рабочем компьютере крайне небезопасно,
а в изолированной среде, которая гарантирует виртуальная машина, вполне
возможно.

Учитываемые факторы при развертывании

виртуальных машин. Управление
виртуальными машинами.
Гипервизор, установленный на физическом компьютере или сервере, позволяет
абстрагировать операционную систему и приложения от аппаратного обеспечения.
Это дает возможность разделить физический сервер на несколько независимых
«виртуальных машин». Таким образом, каждая виртуальная машина независимо от
других виртуальных машин может запускать собственную операционную систему и
приложения и при этом совместно с другими виртуальными машинами использовать
общие ресурсы физического сервера, управляемого гипервизором. Примерами таких
ресурсов являются оперативная память, хранилище и др
Перед началом работы:
● Некоторые параметры, в том числе роли и компоненты сервера, установка
приложения и параметры SQL Server, применяются только при использовании
шаблона виртуальной машины для развертывания служб. При создании
отдельной виртуальной машины эти параметры не используются и не
отображаются.
● Возможность настройки для виртуальной машины статических IP-адресов из
пула IP-адресов под управлением VMM доступна только при развертывании
виртуальной машины с помощью шаблона виртуальной машины.
● Для выполнения описываемых действий необходимо быть администратором
или полномочным администратором на сервере VMM либо пользователем
самообслуживания.
● Если вы являетесь пользователем самообслуживания, вам требуются
разрешения на развертывание с назначенным действием Сохранение и
повторное развертывание . Вам необходимо сначала развернуть виртуальную
машину в частном облаке, а затем сохранить ее в библиотеке.
● Настраивать параметры статических IP-адресов можно только при создании
виртуальной машины на основе шаблона виртуальной машины.
● VMM можно использовать для настройки параметров доступности для
виртуальной машины.
Основные особенности средства виртуальных машин в центре администрирования
Windows:
● Высокоуровневое отслеживание ресурсов узла Hyper-V. Просмотр общего
использования ЦП и памяти, метрики производительности операций ввода-
вывода, оповещения о работоспособности виртуальной машины и события для
сервера узла Hyper-V или всего кластера на одной панели мониторинга.
 ● Единый интерфейс, объединяющий диспетчер Hyper-V и диспетчер
отказоустойчивости кластеров возможности. Просмотр всех виртуальных
машин в кластере и подробное изучение одной виртуальной машины для
расширенного управления и устранения неполадок.
● Упрощенные, но мощные рабочие процессы для управления виртуальными
машинами. Новые возможности пользовательского интерфейса,
предназначенные для сценариев администрирования ИТ для создания,
управления и репликации виртуальных машин.
Задачи Hyper-V, которые можно выполнять в центре администрирования Windows:
● Мониторинг ресурсов и производительности узла Hyper-V
● Просмотр инвентаризации виртуальных машин
● Создание новой виртуальной машины
● Изменение параметров виртуальной машины
● Динамическая миграция виртуальной машины на другой узел кластера
● Расширенное управление и устранение неполадок для одной виртуальной
машины
● Управление виртуальной машиной с помощью узла Hyper-V (VMConnect)
● Изменение параметров узла Hyper-V
● Просмотр журналов событий Hyper-V
● Защита виртуальных машин с помощью Azure Site Recovery

Облачное хранилище. Неструктурированные

данные. Структурированные данные.
Облачное хранилище данных (англ. cloud storage) — модель онлайн-хранилища, в
котором данные хранятся на многочисленных распределённых в сети серверах,
предоставляемых в пользование клиентам, в основном, третьей стороной. В отличие
от модели хранения данных на собственных выделенных серверах, приобретаемых
или арендуемых специально для подобных целей, количество или какая-либо
внутренняя структура серверов клиенту, в общем случае, не видна. Данные хранятся и
обрабатываются в так называемом «облаке», которое представляет собой, с точки
зрения клиента, один большой виртуальный сервер. Физически же такие серверы
могут располагаться удалённо друг от друга географически.
Облачными хранилищами являются такие интернет-сервисы, как: Dropbox, OneDrive,
Google Drive, iCloud, Яндекс.Диск, Облако Mail.Ru, и другие.
Преимущества:
● Возможность доступа к данным из любого компьютера, имеющего выход в
интернет
● Возможность организации совместной работы с данными
● Высокая вероятность сохранения данных даже в случае аппаратных сбоев
● Клиент платит только за то место в хранилище, которое фактически
использует, но не за аренду сервера, все ресурсы которого он может и не
использовать.
● Клиенту нет необходимости заниматься приобретением, поддержкой и
обслуживанием собственной инфраструктуры по хранению данных, что, в
конечном счете, уменьшает общие издержки производства.
 ● Все процедуры по резервированию и сохранению целостности данных
предоставляются провайдером «облачного» центра, который не вовлекает в
этот процесс клиента.
Неструктурированные данные (или неструктурированная информация ) - это
информация, которая либо не имеет заранее определенной модели данных, либо не
организована заранее определенным образом. Неструктурированная информация
обычно имеет объемный текст , но может также содержать такие данные, как даты,
числа и факты. Это приводит к неточностям и двусмысленностям, которые затрудняют
понимание использования традиционных программ по сравнению с данными,
хранящимися в полевой форме в базах данных или аннотированных (семантически
помеченных) в документах.
Работа с неструктурированными данными
Такие методы, как интеллектуальный анализ данных , обработка естественного языка
(NLP) и текстовая аналитика, предоставляют различные методы для поиска
закономерностей или иной интерпретации этой информации. Общие методы
структурирования текста обычно включают ручную маркировку метаданными или теги
части речи для дальнейшего структурирования на основе интеллектуального анализа
текста . Стандарт архитектуры управления неструктурированной информацией (UIMA)
предоставляет общую основу для обработки этой информации с целью извлечения
смысла и создания структурированных данных об информации. Программное
обеспечение, которое создает машинно-обрабатываемую структуру, может
использовать лингвистическую, звуковую и визуальную структуру, которая существует
во всех формах человеческого общения. Алгоритмы могут вывести эту внутреннюю
структуру из текста, например, исследуя морфологию слова , синтаксис предложения
и другие мелкие и крупномасштабные шаблоны. Затем неструктурированная
информация может быть обогащена и помечена для устранения двусмысленностей и
методов, основанных на релевантности, а затем использоваться для облегчения
поиска и обнаружения. Примеры «неструктурированных данных» могут включать
книги, журналы, документы, метаданные , медицинские записи , аудио , видео ,
аналоговые данные , изображения, файлы и неструктурированный текст, такой как
тело сообщения электронной почты , веб-страница или слово- документ обработчика .
Хотя основной передаваемый контент не имеет определенной структуры, он обычно
поставляется упакованным в объекты (например, в файлы или документы, ...), которые
сами имеют структуру и, таким образом, представляют собой смесь
структурированных и неструктурированных данных, но в совокупности это все еще
называются «неструктурированными данными». Например, веб-страница HTML
помечена тегами, но разметка HTML обычно служит исключительно для визуализации.
Он не фиксирует значение или функцию помеченных элементов способами, которые
поддерживают автоматическую обработку информационного содержания страницы.
Тегирование XHTML допускает машинную обработку элементов, хотя обычно не
фиксирует и не передает семантическое значение тегированных терминов. Поскольку
неструктурированные данные обычно встречаются в электронных документах ,
использование системы управления содержанием или документами, которая может
классифицировать документы целиком, часто предпочтительнее передачи данных и
манипулирования ими из документов. Таким образом, управление документами
предоставляет средства для передачи структуры коллекциям документов . Поисковые
системы стали популярными инструментами для индексации и поиска таких данных,
особенно текста.
Подходы к обработке естественного языка
Были разработаны специальные вычислительные рабочие процессы для наложения
структуры на неструктурированные данные, содержащиеся в текстовых документах.
Эти рабочие процессы обычно предназначены для обработки наборов из тысяч или
даже миллионов документов, или гораздо большего количества, чем может позволить
ручной подход к аннотации. Некоторые из этих подходов основаны на концепции
онлайн-аналитической обработки или OLAP и могут поддерживаться моделями
данных, такими как текстовые кубы. Как только метаданные документа становятся
доступными через модель данных, создание сводок подмножеств документов (т. Е.
Ячеек в текстовом кубе) может быть выполнено с помощью подходов, основанных на
фразах.
Подходы в медицине и биомедицинских исследованиях
Биомедицинские исследования являются одним из основных источников
неструктурированных данных, поскольку исследователи часто публикуют свои выводы
в научных журналах. Хотя язык в этих документах сложно вывести из структурных
элементов (например, из-за сложного технического словаря, содержащегося внутри, и
знаний предметной области, необходимых для полной контекстуализации
наблюдений), результаты этих действий могут дать связи между техническими и
медицинскими исследованиями и подсказками. относительно новых методов лечения
болезней. Недавние усилия по обеспечению структуры в биомедицинских документах
включают подходы к самоорганизующейся карте для определения тем среди
документов, универсальные неконтролируемые алгоритмы и применение рабочего
процесса CaseOLAP для определения ассоциаций между названиями белков и
темами о сердечно-сосудистых заболеваниях в литературе. CaseOLAP определяет
отношения фраза-категория точным (идентифицирующим отношения),
последовательным (воспроизводимым) и эффективным способом. Эта платформа
предлагает расширенную доступность и предоставляет биомедицинскому сообществу
инструменты для анализа фраз для широко распространенных приложений
биомедицинских исследований.
Структурированными называются данные, отражающие отдельные факты
предметной области и упорядоченные определенным образом с целью обеспечения
возможности применения к ним различных методов обработки. В этом случае
подразумевается, что данные упорядочены по вертикали в типизированные столбцы,
называемые полями, а по горизонтальные в строки, называемые записями.
При этом все записи должны содержать один и тот же набор полей, а все поля – один
и тот же набор записей. Обычно, каждое поле представляет собой атрибут атрибут
(признак), а строка - единицу наблюдения.
Большинство алгоритмов машинного обучения, статистического и интеллектуального
анализа данных работают только со структурированными данными.

Что такое транзакция? Что такое гарантии

ACID?
Транзакция — это набор действий с данными, объединенный в логическую единицу.
Она либо выполняется целиком, либо нет. Классический пример с операцией
перевода денег со счета на счет:
➢ начать транзакцию
 ➢ прочесть баланс на счету номер 5
➢ уменьшить баланс на 10 денежных единиц
➢ сохранить новый баланс счёта номер 5
➢ прочесть баланс на счету номер 7
➢ увеличить баланс на 10 денежных единиц
➢ сохранить новый баланс счёта номер 7
➢ Окончить транзакцию
Если эти операции выполнять вне транзакции, то ошибка в любой из них оставит оба
счета в несогласованном состоянии: например, выйдет так, что деньги снимутся с
одного счета, а на другой не придут. С транзакцией таких проблем нет — при ошибке
откатятся все операции и для пользователя ничего не изменится.
ACID ー это набор из четырех требований к транзакционной системе, обеспечивающих
максимально надежную и предсказуемую работу. Не все базы данных полностью
реализуют ACID.
Атомарность (atomicity)
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не
будет выполнена совсем. Не допускаются промежуточные состояния.
Согласованность (consistency)
Согласованность — это требование, подразумевающее, что в результате работы
транзакции данные будут допустимыми. Это вопрос не технологии, а бизнес-логики:
например, если количество денег на счете не может быть отрицательным, логика
транзакции должна проверять, не выйдет ли в результате отрицательных значений.
Изолированность (isolation)
Гарантия того, что параллельные транзакции не будут оказывать влияния на
результат других транзакций. Мы разобрались с изоляцией выше.
Долговечность (durability)
Изменения, получившиеся в результате транзакции, должны оставаться
сохраненными вне зависимости от каких-либо сбоев. Иначе говоря, если пользователь
получил сигнал о завершении транзакции, он может быть уверен, что данные
сохранены.

OLTP и OLAP. Охарактеризуйте.

OLTP (англ. Online Transaction Processing) или реляционные БД- это базы данных,
которые используются везде и повсеместно. Их основная цель -
ввод/редактирование/удаление данных в режиме онлайн. Примеры использования:
мессенджеры, социальные сети, 1С: Бухгалтерия и т.д.
OLAP (англ. Online Analytical Processing) или многомерные БД - это базы данных,
которые служат непосредственно для проведения быстрого анализа больших объемов
данных. Обычно такие БД используются на больших предприятиях для построения
аналитической отчетности за большой промежуток времени (месяц, квартал, год).
Такая информация в основном используется для анализа прошедшего периода и
планирования будущего. Основные пользователи аналитических данных -
руководители.
Принципиальное отличие этих БД заключается в том, что OLAP выбирает
данные быстрее, чем OLTP
Есть такое понятие, как нормализация - оно подразумевает хранение информации
максимально просто и не избыточно. Максимально просто: не хранить в одном
столбце ФИО, а сделать 3 отдельных. Не избыточно: фамилия клиента должна
храниться только в справочнике клиентов, и ее не нужно добавлять в сделанные
клиентом заказы.
Денормализация - процесс противоположный нормализации.
OLTP придерживаются принципов нормализации, OLAP - денормализации.
В базах данных OLAP в центре находится таблица фактов, в которой находятся все
показатели (сумма, кол-во) и ссылки на справочники.
А в OLTP одна таблица цепляется за другую без наличия общего связующего звена.

Структурное хранилище. SQL Database.

SQL (Structured Query Language) — язык структурированных запросов, с помощью
него пишутся специальные запросы (так называемые SQL инструкции) к базе данных с
целью получения данных из базы данных или для манипулирования этими данными.
Также обязательно стоит отметить и то, что база данных, и в частности реляционная
модель, основана на теории множеств, которая подразумевает объединение разных
объектов в одно целое, под одним целым в базе данных как раз и имеется в виду
таблица. Это важно, так как язык SQL работает именно со множеством, с набором
данных, т.е. с таблицами.
SQL остаётся самым распространённым лингвистическим средством для
взаимодействия прикладного программного обеспечения с базами данных. В то же
время современные СУБД, а также информационные системы, использующие СУБД,
предоставляют пользователю развитые средства визуального построения запросов
Преимущества:
● Независимость от конкретной СУБД. Несмотря на наличие диалектов и
различий в синтаксисе, в большинстве своем тексты SQL-запросов,
содержащие DDL и DML, могут быть достаточно легко перенесены из одной
СУБД в другую. Существуют системы, разработчики которых изначально
ориентировались на применение по меньшей мере нескольких СУБД
(например: система электронного документооборота Documentum может
работать как с Oracle Database, так и с Microsoft SQL Server и DB2).
Естественно, что при применении некоторых специфичных для реализации
возможностей такой переносимости добиться уже очень трудно.
● Наличие стандартов. Наличие стандартов и набора тестов для выявления
совместимости и соответствия конкретной реализации SQL общепринятому
стандарту только способствует «стабилизации» языка. Правда, стоит обратить
внимание, что сам по себе стандарт местами чересчур формализован и раздут
в размерах (например, базовая часть стандарта SQL:2003 состоит из более чем
1300 страниц текста).
● Декларативность. С помощью SQL программист описывает только то, какие
данные нужно извлечь или модифицировать. То, каким образом это сделать,
решает СУБД непосредственно при обработке SQL-запроса. Однако не стоит
думать, что это полностью универсальный принцип — программист описывает
набор данных для выборки или модификации, однако ему при этом полезно
представлять, как СУБД будет разбирать текст его запроса. Чем сложнее
 сконструирован запрос, тем больше он допускает вариантов написания,
различных по скорости выполнения, но одинаковых по итоговому набору
данных.
Недостатки:
● Несоответствие реляционной модели данных
Создатели реляционной модели данных Эдгар Кодд, Кристофер Дейт и их
сторонники указывают на то, что SQL не является истинно реляционным
языком. В частности, они указывают на следующие дефекты SQL с точки
зрения реляционной теории:
○ допущение строк-дубликатов в таблицах и результатах выборок, что в
рамках реляционной модели данных невозможно и недопустимо;
○ поддержка неопределенных значений (NULL), создающую фактически
многозначную логику;
○ значимость порядка столбцов, возможность ссылок на столбцы по
номерам (в реляционной модели столбцы должны быть равноправны);
○ допущение столбцов без имени, дублирующихся имен столбцов.
В опубликованном Кристофером Дейтом и Хью Дарвеном Третьем манифесте
они излагают принципы СУБД следующего поколения и предлагают язык
Tutorial D, который является подлинно реляционным.
● Сложность
Хотя SQL и задумывался как средство работы конечного пользователя, позже
он стал настолько сложным, что превратился в инструмент программиста.
● Отступления от стандартов
Несмотря на наличие международного стандарта ANSI SQL-92, многие
разработчики СУБД вносят изменения в язык SQL, применяемый в
разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом
появляются специфичные для каждой конкретной СУБД диалекты языка SQL.
● Сложность работы с иерархическими структурами
Ранее диалекты SQL большинства СУБД не предлагали способа манипуляции
древовидными структурами. Некоторые поставщики СУБД предлагали свои
решения (например, в Oracle Database используется выражение CONNECT BY).
В настоящее время в ANSI стандартизована рекурсивная конструкция WITH из
диалекта SQL DB2. В Microsoft SQL Server рекурсивные запросы (Recursive
Common Table Expressions) появились с версии 2005

Методики класса гибких методологий

разработки.
Гибкая разработка ПО (англ. Agile software development), agile-методы —
обобщающий термин для целого ряда подходов и практик, основанных на ценностях
Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в
его основе.
К гибкой разработке, в частности, относят экстремальное программирование, DSDM,
Scrum, FDD, BDD и др.
Применяется как эффективная практика организации труда небольших групп (которые
делают однородную творческую работу) в объединении с управлением ими
комбинированным (либеральным и демократическим) методом.
Большинство гибких практик нацелены на минимизацию рисков путём сведения
разработки к серии коротких циклов, называемых итерациями, которые обычно длятся
две-три недели. Каждая итерация сама по себе выглядит как программный проект в
миниатюре и включает все задачи, необходимые для выдачи мини-прироста по
функциональности: планирование, анализ требований, проектирование,
программирование, тестирование и документирование. Хотя отдельная итерация, как
правило, недостаточна для выпуска новой версии продукта, подразумевается, что
гибкий программный проект готов к выпуску в конце каждой итерации. По окончании
каждой итерации команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственном общении лицом к лицу. Большинство
agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как
минимум, она включает и «заказчиков» (англ. product owner — заказчик или его
полномочный представитель, определяющий требования к продукту; эту роль может
выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также
включать тестировщиков, дизайнеров интерфейса, технических писателей и
менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение
непосредственному общению, agile-методы уменьшают объём письменной
документации по сравнению с другими методами. Это привело к критике этих методов
как недисциплинированных.
Методологии
Существуют методологии, которые придерживаются ценностей и принципов
заявленных в Agile Manifesto, некоторые из них:
● Agile Modeling — набор понятий, принципов и приемов (практик), позволяющих
быстро и просто выполнять моделирование и документирование в проектах
разработки программного обеспечения. Не включает в себя детальную
инструкцию по проектированию, не содержит описаний, как строить диаграммы
на UML. Основная цель: эффективное моделирование и документирование; но
не охватывает программирование и тестирование, не включает вопросы
управления проектом, развертывания и сопровождения системы. Однако
включает в себя проверку модели кодом.
● Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process
(RUP), разработанная Скоттом Амблером, которая описывает простое и
понятное приближение (модель) для создания программного обеспечения для
бизнес-приложений.
● Agile Data Method — группа итеративных методов разработки программного
обеспечения, в которых требования и решения достигаются в рамках
сотрудничества разных кросс-функциональных команд.
● DSDM основан на концепции быстрой разработки приложений (Rapid Application
Development, RAD). Представляет собой итеративный и инкрементный подход,
который придаёт особое значение продолжительному участию в процессе
пользователя/потребителя.
● Essential Unified Process (англ.) (EssUP).
● Экстремальное программирование (англ. Extreme programming, XP).
● Feature driven development (FDD) — функционально-ориентированная
разработка. Используемое в FDD понятие функции или свойства (англ. feature)
системы достаточно близко к понятию прецедента использования,
используемому в RUP, существенное отличие — это дополнительное
 ограничение: «каждая функция должна допускать реализацию не более, чем за
две недели». То есть если сценарий использования достаточно мал, его можно
считать функцией. Если же велик, то его надо разбить на несколько
относительно независимых функций.
● Getting Real — итеративный подход без функциональных спецификаций,
использующийся для веб-приложений. В данном методе сперва
разрабатывается интерфейс программы, а потом её функциональная часть.
● OpenUP — это итеративно-инкрементальный метод разработки программного
обеспечения. Позиционируется как легкий и гибкий вариант RUP. OpenUP
делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы
уточнения, конструирования и передачи. Жизненный цикл проекта
обеспечивает предоставление заинтересованным лицам и членам коллектива
точек ознакомления и принятия решений на протяжении всего проекта. Это
позволяет эффективно контролировать ситуацию и вовремя принимать
решения о приемлемости результатов. План проекта определяет жизненный
цикл, а конечным результатом является окончательное приложение.
● Scrum устанавливает правила управления процессом разработки и позволяет
использовать уже существующие практики кодирования, корректируя
требования или внося тактические изменения. Использование этой
методологии дает возможность выявлять и устранять отклонения от желаемого
результата на более ранних этапах разработки программного продукта.
● Бережливая разработка программного обеспечения (англ. lean software
development) использует подходы из концепции бережливого производства.

Веб-хостинг.
Веб хостинг (англ. web hosting) — услуга по предоставлению ресурсов для
размещения информации на сервере, постоянно находящемся в сети (обычно
Интернет).
Обычно хостинг входит в пакет по обслуживанию сайта и подразумевает как минимум
услугу размещения файлов сайта на сервере, на котором запущено ПО, необходимое
для обработки запросов к этим файлам (веб-сервер). Как правило, в обслуживание
уже входит предоставление места для почтовой корреспонденции, баз данных, DNS,
файлового хранилища на специально выделенном файл-сервере и т. п., а также
поддержка функционирования соответствующих сервисов. (Wiki.)
На одном сервере может быть достаточно много сайтов — их количество зависит от
количества свободного дискового пространства. Кроме того, важны вычислительные
мощности и пропускные способности интернет-каналов..
Одной из наиболее распространенных хостинговых услуг является так называемый
виртуальный хостинг (англ. shared hosting), при котором множество веб-сайтов
располагаются на одном сервере. Обычно каждый сайт занимает отдельную папку на
сервере, но при этом для управления всем множеством сайтов используется единое
ПО (веб-сервер, сервер баз данных и т.п.)
Веб-хостинг и облачный веб-хостинг.
Сравнение возможностей.
Хостинг – это своеобразная аренда пространства на сервере, где будут храниться
данные и файлы для функционирования сайта. Хостинги призваны решать различные
задачи пользователей, поэтому выделяют несколько их видов. Чем больше сайт, тем
больше ему понадобится пространства для размещения.
На рынке хостинг-услуг пользователям доступны пять основных видов хостинга:
● виртуальный хостинг (Shared) — это сервер, на котором расположено
множество сайтов. Они используют одинаковое программное обеспечение и
имеют равные возможности. На одном сервере может находиться около тысячи
сайтов. Как правило, на таком хостинге располагают небольшие веб-ресурсы,
не требующие больших мощностей и дискового пространства. Благодаря своей
низкой стоимости и отсутствию необходимости в администрировании сервера,
виртуальный хостинг — самый распространенный выбор среди пользователей.
● виртуальный выделенный сервер (VPS-сервер). VPS отличается от
виртуального хостинга тем, что владелец такого сервера может устанавливать
и настраивать любое программное обеспечение. По сути, управление VPS-
сервером не отличается от управления физическим сервером. Сайту на VPS
выделены определенные ресурсы в соответствии с тарифом. Это не всегда
возможно при использовании Shared-хостинга, где ресурсы сервера
равномерно распределяются между всеми сайтами.
● выделенный физический сервер (Dedicated). Пользователю дается отдельный
сервер в дата-центре под самостоятельное управление с возможностью
устанавливать любую операционную систему, менять программное
обеспечение под свои нужды. Такой хостинг используется для масштабных
ресурсоемких проектов с высокими требованиями и хорошо подойдет для
крупных интернет-магазинов с высокой посещаемостью или, например, онлайн-
игр.
● облачный хостинг (Cloud hosting) — объединённая система серверов, на
которых располагаются клиентские сайты. Таким образом, выделяемые для
клиента мощности не ограничиваются одним сервером, а распределяются
сразу между несколькими серверами. Это обеспечивает бесперебойную
работу ресурса вне зависимости от выхода из строя какого-то одного сервера.
Кроме повышенной производительности, облачный хостинг привлекает
клиентов и другими преимуществами. Во-первых, пользователь платит только
за те ресурсы, которые использовал — цена услуги зависит от объемов
потребления мощностей. Во-вторых, на облачном хостинге при изменении
нагрузки выделенные ресурсы увеличиваются или уменьшаются
автоматически. Благодаря такому распределению мощностей клиенту не нужно
рассчитывать возможные объемы потребления ресурсов для правильного
выбора тарифа.
● colocation (размещение оборудования клиента в дата-центре провайдера).
Colocation буквально переводится как «соразмещение», что точно описывает
этот вид хостинг-услуг. Ваш сервер располагается на технологической
площадке провайдера (дата-центре), который обеспечивает его
высокоскоростным интернет-каналом и заботится о прочих необходимых
 условиях содержания. По сравнению с остальными видами хостинга Colocation
даёт своему владельцу наибольшую свободу для воплощения идей, но для
работы с ним требуются соответствующие технические знания. Таким образом,
развитие веб-проекта ограничивается лишь вашей фантазией и навыками —
любые необходимые технические параметры, такие как объем дискового
пространства или новое ПО, можно будет добавить по мере необходимости.
Для сайтов с небольшим количеством контента и небольшой аудиторией подойдет
виртуальный хостинг. Альтернатива — облачный хостинг, потому что вы платите
только за те ресурсы, которые использовали.
Если же вы управляете специфичным сайтом, для которого требуются определенные
настройки сервера, закажите услугу VPS-хостинга. А для серьезных ресурсоемких веб-
проектов лучше взять в аренду физический сервер или colocation.
Облачный хостинг обеспечивает доступ к приложениям и веб-сайтам через
облачные ресурсы. В отличие от обычного хостинга решения не развертываются на
одном сервере. Вместо этого приложение или сайт размещается в сети связанных
виртуальных и физических облачных серверов, что гарантирует гибкость и
масштабируемость.
Основные возможности:
● Приложения и решения развертываются в облачной сети, а не на отдельном
локальном сервере.
● Ресурсы масштабируются в зависимости от нужд пользователя.
● Организации платят только за используемые ресурсы.
● Есть поддержка баз данных SQL (включая MySQL) и NoSQL.
● Решения автоматизированы и управляются через API, веб-порталы и
мобильные приложения.

Структура информации на сайте одновременно влияет на два показателя:

пользовательский фактор и эффективность и скорость ранжирования ресурса
поисковиком. Следовательно, разработка схемы должна одновременно удовлетворять
требования и потребителя, и поисковой системы.
3 главных правила построения структуры сайта:
● Структура должна быть максимально понятной посетителю. Градация всех
товаров по их предназначению должна быть интуитивно доступна
● Вложенность страниц каталога должна быть максимально оптимизирована и
логична.
● Простая навигация.
Любая структура сайта независимо от его вида напоминает древовидную схему, где
главная страница - это ствол, а категории и подкатегории - ветки и листья. И если
главная - это основа, без нее не обойтись в любом сайте, то принцип размещения и
построения категорий и подкатегорий зависит от вида сайта и его целей.
для любого сайта должно выполнятся правило 3 кликов. То есть любая важная
информация должна находится не более чем через 3 клика
Принципы масштабируемости. Архитектура
сайта.
Масштабируемость — способность устройства увеличивать свои возможности путем
наращивания числа функциональных блоков, выполняющих одни и те же задачи.
Типичная архитектура сайта
Жизнь типичного сайта начинается с очень простой архитектуры — это один web-
сервер (обычно в его роли выступает Apache), который занимается всей работой по
обслуживанию HTTP-запросов, поступающих от посетителей. Он отдает клиентам так
называемую «статику», то есть файлы, лежащие на диске сервера и не требующие
обработки: картинки (gif, jpg, png), листы стилей (css), клиентские скрипты (js, swf). Тот
же сервер отвечает на запросы, требующие вычислений — обычно это формирование
html-страниц, хотя иногда «на лету» создаются и изображения и другие документы.
Чаще всего ответы на такие запросы формируются скриптами, написанными на php,
perl или других языках.
Минус такой простой схемы работы в том, что разные по характеру запросы (отдача
файлов с диска и вычислительная работа скриптов) обрабатываются одним и тем же
web-сервером. Вычислительные запросы требуют держать в памяти сервера много
информации (интерпретатор скриптового языка, сами скрипты, данные, с которыми
они работают) и могут занимать много вычислительных ресурсов. Выдача статики,
наоборот, требует мало ресурсов процессора, но может занимать продолжительное
время, если у клиента низкая скорость связи. Внутреннее устройство сервера Apache
предполагает, что каждое соединение обрабатывается отдельным процессом. Это
удобно для работы скриптов, однако неоптимально для обработки простых запросов.
Получается, что тяжелые (от скриптов и прочих данных) процессы Apache много
времени проводят в ожидании (сначала при получении запроса, затем при отправке
ответа), впустую занимая память сервера.
Решение этой проблемы — распределение работы по обработке запросов между
двумя разными программами — т.е. разделение на frontend и backend. Легкий frontend-
сервер выполняет задачи по отдаче статики, а остальные запросы перенаправляет
(проксирует) на backend, где выполняется формирование страниц. Ожидание
медленных клиентов также берет на себя frontend, и если он использует
мультиплексирование (когда один процесс обслуживает нескольких клиентов — так
работают, например, nginx или lighttpd), то ожидание практически ничего не стоит.
Из других компонент сайта следует отметить базу данных, в которой обычно хранятся
основные данные системы — тут наиболее популярны бесплатные СУБД MySQL и
PostgreSQL. Часто отдельно выделяется хранилище бинарных файлов, где
содержатся картинки (например, иллюстрации к статьям сайта, аватары и фотографии
пользователей) или другие файлы.
Обычно в начале жизни сайта все компоненты архитектуры располагаются на одном
сервере. Если он перестает справляться с нагрузкой, то есть простое решение —
вынести наиболее легко отделяемые части на другой сервер. Проще всего начать с
базы данных — перенести ее на отдельный сервер и изменить реквизиты доступа в
скриптах. Кстати, в этот момент мы сталкиваемся с важностью правильной
архитектуры программного кода. Если работа с базой данных вынесена в отдельный
модуль, общий для всего сайта — то исправить параметры соединения будет просто.
Пути дальнейшего разделения компонент тоже понятны — например, можно вынести
frontend на отдельный сервер. Но обычно frontend требует мало системных ресурсов и
на этом этапе его вынос не даст существенного прироста производительности. Чаще
всего сайт упирается в производительность скриптов — формирование ответа (html-
страницы) занимает слишком долгое время. Поэтому следующим шагом обычно
является масштабирование backend-сервера.
Распределение вычислений
Типичная ситуация для растущего сайта — база данных уже вынесена на отдельную
машину, разделение на frontend и backend выполнено, однако посещаемость
продолжает увеличиваться и backend не успевает обрабатывать запросы. Это значит,
что нам необходимо распределить вычисления на несколько серверов. Сделать это
просто — достаточно купить второй сервер и поставить на него программы и скрипты,
необходимые для работы backend. После этого надо сделать так, чтобы запросы
пользователей распределялись (балансировались) между полученными серверами. О
разных способах балансировки будет сказано ниже, пока же отметим, что обычно этим
занимается frontend, который настраивают так, чтобы он равномерно распределял
запросы между серверами.
Важно, чтобы все backend-серверы были способны правильно отвечать на запросы.
Обычно для этого необходимо, чтобы каждый из них работал с одним и тем же
актуальным набором данных. Если мы храним всю информацию в единой базе
данных, то СУБД сама обеспечит совместный доступ и согласованность данных. Если
же некоторые данные хранятся локально на сервере (например, php-сессии клиента),
то стоит подумать о переносе их в общее хранилище, либо о более сложном
алгоритме распределения запросов.
Распределить по нескольким серверам можно не только работу скриптов, но и
вычисления, производимые базой данных. Если СУБД выполняет много сложных
запросов, занимая процессорное время сервера, можно создать несколько копий базы
данных на разных серверах. При этом возникает вопрос синхронизации данных при
изменениях, и здесь применимы несколько подходов:
● Синхронизация на уровне приложения. В этом случае наши скрипты
самостоятельно записывают изменения на все копии базы данных (и сами
несут ответственность за правильность данных). Это не лучший вариант,
поскольку он требует осторожности при реализации и весьма неустойчив к
ошибкам.
● Репликация — то есть автоматическое тиражирование изменений, сделанных
на одном сервере, на все остальные сервера. Обычно при использовании
репликации изменения записываются всегда на один и тот же сервер — его
называют master, а остальные копии — slave. В большинстве СУБД есть
встроенные или внешние средства для организации репликации. Различают
синхронную репликацию — в этом случае запрос на изменение данных будет
ожидать, пока данные будут скопированы на все сервера, и лишь потом
завершится успешно — и асинхронную — в этом случае изменения копируются
на slave-сервера с задержкой, зато запрос на запись завершается быстрее.
● Multi-master репликация. Этот подход аналогичен предыдущему, однако тут мы
можем производить изменение данных, обращаясь не к одному определенному
серверу, а к любой копии базы. При этом изменения синхронно или асинхронно
попадут на другие копии. Иногда такую схему называют термином «кластер
базы данных».
Возможны разные варианты распределения системы по серверам.
Например, у нас может быть один сервер базы данных и несколько backend (весьма
типичная схема), или наоборот — один backend и несколько БД. А если мы
масштабируем и backend-сервера, и базу данных, то можно объединить backend и
копию базы на одной машине. В любом случае, как только у нас появляется несколько
экземпляров какого-либо сервера, возникает вопрос, как правильно распределить
между ними нагрузку.
Методы балансировки
Пусть мы создали несколько серверов (любого назначения — http, база данных и т.п.),
каждый из которых может обрабатывать запросы. Перед нами встает задача — как
распределить между ними работу, как узнать, на какой сервер отправлять запрос?
Возможны два основных способа распределения запросов:
1. Балансирующий узел. В этом случае клиент шлет запрос на один
фиксированный, известный ему сервер, а тот уже перенаправляет запрос на
один из рабочих серверов. Типичный пример — сайт с одним frontend и
несколькими backend-серверами, на которые проксируются запросы. Однако
«клиент» может находиться и внутри нашей системы — например, скрипт
может слать запрос к прокси-серверу базы данных, который передаст запрос
одному из серверов СУБД. Сам балансирующий узел может работать как на
отдельном сервере, так и на одном из рабочих серверов. Преимущества этого
подхода в том, что клиенту ничего не надо знать о внутреннем устройстве
системы — о количестве серверов, об их адресах и особенностях — всю эту
информацию знает только балансировщик. Однако недостаток в том, что
балансирующий узел является единой точкой отказа системы — если он
выйдет из строя, вся система окажется неработоспособна. Кроме того, при
большой нагрузке балансировщик может просто перестать справляться со
своей работой, поэтому такой подход применим не всегда.
2. Балансировка на стороне клиента. Если мы хотим избежать единой точки
отказа, существует альтернативный вариант — поручить выбор сервера
самому клиенту. В этом случае клиент должен знать о внутреннем устройстве
нашей системы, чтобы уметь правильно выбирать, к какому серверу
обращаться. Несомненным плюсом является отсутствие точки отказа — при
отказе одного из серверов клиент сможет обратиться к другим. Однако платой
за это является усложнение логики клиента и меньшая гибкость балансировки.
Разумеется, существуют и комбинации этих подходов. Например, такой
известный способ распределения нагрузки, как DNS-балансировка, основан на
том, что при определении IP-адреса сайта клиенту выдается адрес одного из
нескольких одинаковых серверов. Таким образом, DNS выступает в роли
балансирующего узла, от которого клиент получает «распределение». Однако
сама структура DNS-серверов предполагает отсутствие точки отказа за счет
дублирования — то есть сочетаются достоинства двух подходов. Конечно, у
такого способа балансировки есть и минусы — например, такую систему
сложно динамически перестраивать.
Работа с сайтом обычно не ограничивается одним запросом.
Поэтому при проектировании важно понять, могут ли последовательные запросы
клиента быть корректно обработаны разными серверами, или клиент должен быть
привязан к одному серверу на время работы с сайтом. Это особенно важно, если на
сайте сохраняется временная информация о сессии работы пользователя (в этом
случае тоже возможно свободное распределение — однако тогда необходимо хранить
сессии в общем для всех серверов хранилище). «Привязать» посетителя к
конкретному серверу можно по его IP-адресу (который, однако, может меняться), или
по cookie (в которую заранее записан идентификатор сервера), или даже просто
перенаправив его на нужный домен.
С другой стороны, вычислительные сервера могут быть и не равноправными.
В некоторых случаях выгодно поступить наоборот, выделить отдельный сервер для
обработки запросов какого-то одного типа — и получить вертикальное разделение
функций. Тогда клиент или балансирующий узел будут выбирать сервер в
зависимости от типа поступившего запроса. Такой подход позволяет отделить
важные (или наоборот, не критичные, но тяжелые) запросы от остальных.
Распределение данных
Возможные схемы распределения:
● Вертикальное распределение (vertical partitioning) — в простейшем случае
представляет собой вынесение отдельных таблиц базы данных на другой
сервер. При этом нам потребуется изменить скрипты, чтобы обращаться к
разным серверам за разными данными. В пределе мы можем хранить каждую
таблицу на отдельном сервере (хотя на практике это вряд ли будет выгодно).
Очевидно, что при таком распределении мы теряем возможность делать SQL-
запросы, объединяющие данные из двух таблиц, находящихся на разных
серверах. При необходимости можно реализовать логику объединения в
приложении, но это будет не столь эффективно, как в СУБД. Поэтому при
разбиении базы данных нужно проанализировать связи между таблицами,
чтобы разносить максимально независимые таблицы. Более сложный случай
вертикального распределения базы — это декомпозиция одной таблицы, когда
часть ее столбцов оказывается на одном сервере, а часть — на другом. Такой
прием встречается реже, но он может использоваться, например, для
отделения маленьких и часто обновляемых данных от большого объема редко
используемых.
● Горизонтальное распределение (horizontal partitioning) — заключается в
распределении данных одной таблицы по нескольким серверам. Фактически, на
каждом сервере создается таблица такой же структуры, и в ней хранится
определенная порция данных. Распределять данные по серверам можно по
разным критериям: по диапазону (записи с id < 100000 идут на сервер А,
остальные — на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО»
сохраняем на сервер А, остальные — на сервер Б) или по значению хэш-
функции от некоторого поля записи. Горизонтальное разбиение данных
позволяет хранить неограниченное количество записей, однако усложняет
выборку. Наиболее эффективно можно выбирать записи только когда известно,
на каком сервере они хранятся.
Для выбора правильной схемы распределения данных необходимо внимательно
проанализировать структуру базы. Существующие таблицы (и, возможно, отдельные
поля) можно классифицировать по частоте доступа к записям, по частоте обновления
и по взаимосвязям (необходимости делать выборки из нескольких таблиц).
Распределенные системы хранения файлов (фактически, файловые системы) можно
разделить на два класса:
● Работающие на уровне операционной системы. При этом для приложения
работа с файлами в такой системе не отличается от обычной работы с
файлами. Обмен информацией между серверами берет на себя операционная
 система. В качестве примеров таких файловых систем можно привести давно
известное семейство NFS или менее известную, но более современную
систему Lustre.
● Реализованные на уровне приложения распределенные хранилища
подразумевают, что работу по обмену информацией производит само
приложение. Обычно функции работы с хранилищем для удобства вынесены в
отдельную библиотеку. Один из ярких примеров такого хранилища — MogileFS,
разработанная создателями LiveJournal. Другой распространенный пример —
использование протокола WebDAV и поддерживающего его хранилища.
Надо отметить, что распределение данных решает не только вопрос хранения, но и
частично вопрос распределения нагрузки — на каждом сервере становится меньше
записей, и потому обрабатываются они быстрее. Сочетание методов распределения
вычислений и данных позволяет построить потенциально неограниченно
масштабируемую архитектуру, способную работать с любым количеством данных и
любыми нагрузками.

Распределение хранилища данных. Виды

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

Распределение хранилища данных - случай, когда не будет одного или

нескольких серверов, содержащих полную копию базы данных. Вместо этого, данные
будут распределены по разным серверам
Возможные схемы распределения:
● Вертикальное распределение (vertical partitioning) — в простейшем случае
представляет собой вынесение отдельных таблиц базы данных на другой
сервер. При этом потребуется изменить скрипты, чтобы обращаться к разным
серверам за разными данными. В пределе есть возможность хранить каждую
таблицу на отдельном сервере (хотя на практике это вряд ли будет выгодно).
Очевидно, что при таком распределении теряется возможность делать SQL-
запросы, объединяющие данные из двух таблиц, находящихся на разных
серверах. При необходимости можно реализовать логику объединения в
приложении, но это будет не столь эффективно, как в СУБД. Поэтому при
разбиении базы данных нужно проанализировать связи между таблицами,
чтобы разносить максимально независимые таблицы.
● Горизонтальное распределение (horizontal partitioning) — заключается в
распределении данных одной таблицы по нескольким серверам. Фактически, на
каждом сервере создается таблица такой же структуры, и в ней хранится
определенная порция данных. Распределять данные по серверам можно по
разным критериям: по диапазону (записи с id < 100000 идут на сервер А,
остальные — на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО»
сохраняем на сервер А, остальные — на сервер Б) или по значению хэш-
 функции от некоторого поля записи. Горизонтальное разбиение данных
позволяет хранить неограниченное количество записей, однако усложняет
выборку. Наиболее эффективно можно выбирать записи только когда известно,
на каком сервере они хранятся.
Виды масштабирования хранилищ данных:
● Партиционирование (partitioning)
Партиционирование — это разбиение таблиц, содержащих большое количество
записей, на логические части по неким выбранным администратором
критериям. Партиционирование таблиц делит весь объем операций по
обработке данных на несколько независимых и параллельно выполняющихся
потоков, что существенно ускоряет работу СУБД. Для правильного
конфигурирования параметров партиционирования необходимо, чтобы в
каждом потоке было примерно одинаковое количество записей.
● Репликация (replication)
Репликация — это синхронное или асинхронное копирование данных между
несколькими серверами. Ведущие сервера называют мастерами (master), а
ведомые сервера — слэйвами (slave). Мастера используются для изменения
данных, а слэйвы — для считывания. В классической схеме репликации обычно
один мастер и несколько слэйвов, так как в большей части веб-проектов
операций чтения на несколько порядков больше, чем операций записи. Однако
в более сложной схеме репликации может быть и несколько мастеров.
● Шардинг (sharding)
Шардинг — это прием, который позволяет распределять данные между
разными физическими серверами. Процесс шардинга предполагает разнесения
данных между отдельными шардами на основе некоего ключа шардинга.
Связанные одинаковым значением ключа шардинга сущности группируются в
набор данных по заданному ключу, а этот набор хранится в пределах одного
физического шарда. Это существенно облегчает обработку данных.

Масштабирование виртуальных машин.

Планирование масштабирования.
Перенос инфраструктуры или отдельных приложений в облако провайдера имеет ряд
технических, организационных и финансовых преимуществ. Однако успех миграции
зависит от правильной конфигурации виртуальной среды и настройки самих
виртуальных машин.
Предварительное планирование
Среди подготовительных мер особое внимание следует уделить сайзингу — размеру
будущей инфраструктуры. В облачной инфраструктуре не всегда работает правило
«больше, значит лучше», ресурсы необходимо выделять, проанализировав данные
мониторинга. Полученные сведения позволят определить объем ресурсов, которые
потребуются для будущих виртуальных машин в облаке провайдера.
Перенос приложений из локальной инфраструктуры в облачную требует
обязательного контроля корректности работы программного обеспечения. Работа
приложения внутри виртуальной машины может отличатся от локальной, прежде чем
его запускать его в «продакшен» необходимо выполнить тестирование. Следующая
методика позволит оценить корректность работы:
 ● Необходимо запустить ВМ на одном из серверов ESXi и зарезервировать на
нем ресурсы процессора и памяти.
● Провести тестирование производительности и стабильности работы
приложения.
● Результаты теста занести в baseline. Результаты должны содержать
информацию о работе приложения на архитектуре виртуальной среды в
отсутствии рабочей нагрузки на хосте.
● После сбора статистики хост нагружается — на нем запускаются
дополнительные виртуальные машины, за каждой из которых также закреплены
выделенные ресурсы процессора и памяти.
● Запускается новый тест производительности, а результаты сравниваются с
записями в baseline.
● Анализируя полученные данные важно понять, остается ли
производительность ВМ на уровне, достаточном для функционирования
сервисов. Если это так, то можно добавлять еще нагрузки, отслеживать
распределение ресурсов и выяснить предельную нагрузку для данного хоста.
Данная методика позволит грамотно рассчитать нагрузку на хост арендуемой
виртуальной инфраструктур и не допустить падения производительности приложений
в рабочем режиме.
Особенности правильной настройки виртуальных машин
Большинство облачных провайдеров используют платформу VMware для
предоставления услуги виртуальной инфраструктуры IaaS. Настраивая виртуальные
машины в этой среде, важно обратить внимание на число виртуальных процессоров.
Рекомендуется не использовать больше 8 vCPU. Ограничения обусловлены
использованием архитектуры неравномерного доступа к памяти — NUMA. Если
виртуальной машине назначено больше ядер и оперативной памяти, чем физически
приходится на один процессор, она начнет обращение к другому процессору, это
процесс медленный и снижает производительность ВМ. В NUMA-архитектуре для
каждого процессора выделяется собственная локальная память, совокупность CPU и
RAM объединяется в NUMA-узел. Если ВМ не хватает ресурсов своего узла, она
обращается к памяти другого, скорость такой транзакции медленнее чем при работе с
локальной RAM. Идеально, когда виртуальная машина работает с одним физическим
NUMA-узлом. Используя параметр cores per socket можно определить варианты
отображения нескольких виртуальных процессоров внутри одной ВМ — один CPU с
несколькими ядрами, несколько CPU с одним ядром и другие. Если ВМ будет работать
на одном физическом NUMA-узле, тогда любой из вариантов cores per socket не
скажется на производительности, работа конкретного приложения будет зависеть от
его способности работать с многопроцессорной или многоядерной системой.
Для примера возьмем процесс переноса в облако IaaS базы данных SQL Server 2012
версии Standard. Данная база данных не может использовать больше 4 процессорных
сокетов. Следовательно, для того чтобы запустить ее на виртуальной машине с 32
виртуальными процессорами или потоками, необходимо в настройках ВМ указать
комбинацию 4 сокетов CPU по 8 ядер на каждом.
Как добавлять ресурсы ВМ на лету
Если в процессе работы виртуальной машины ее производительности становится
недостаточно, платформа VMware позволяет добавить вычислительные ресурсы без
остановки машины — на лету. Для этого необходимо воспользоваться опцией Hot Add,
с помощью которой можно увеличить ресурсы процессора и объем назначенной
оперативной памяти.
Однако, Hot Add для процессора (в настройках ВМ — Hot Plug) отключает vNUMA.
В результате, операционная система ВМ будет расценивать всю свободную память
как доступную без разделения по узлам NUMA, что может привести к падению
производительности, так как доступ к памяти другого процессора более медленный.
Прежде чем включить Hot Add для процессора необходимо проанализировать как это
скажется на конкретном приложении.
Разница в подходах масштабирования Scale UP и Scale OUT
Вариант вертикального масштабирования Scale UP выбирают, как наиболее простой и
понятный. Все приложения и базы данных с одного мощного локального хоста
переносят на одну виртуальную машину, а в случае, когда ее ресурсов начинает не
хватать, администратор добавляет еще оперативной памяти и число процессоров или
ядер.
В свою очередь при использовании горизонтального масштабирования — Scale OUT,
мощность локального хоста распределяется между несколькими виртуальными
машинам в составе одного кластера. К преимуществам такого подхода можно отнести
большую гибкость по управлению производительностью каждого из приложений, а
также большую отказоустойчивость, так как в случае выхода из строя одной
вычислительной единицы (виртуального сервера), остальная инфраструктура
продолжает работать.
Настройка использования оперативной памяти
В процессе распределения оперативной памяти между виртуальными машинами
следует помнить про обслуживание физического хоста. Для его нормального
функционирования требуется зарезервировать несколько гигабайт RAM, который не
будет задействован при создании ВМ.
Платформа VMware позволяет выделять виртуальным машинам виртуальной
оперативной памяти больше, чем ее есть физической. Например, создав на хосте,
оснащенном 140 Гб физической оперативной памяти 5 виртуальных машин, каждой из
которых назначены по 32 Гб виртуальной памяти, конфигурация будет работать.
Виртуальные машины будут обращаться к свободной в данный момент RAM и считать,
что она доступна в полном объеме, но в случае пиковой нагрузки производительность
резко упадет. Такой сценарий лучше не использовать. Заранее спланируйте как будет
распределяться доступная физическая память между созданными виртуальными
машинами.

Распределенные атаки типа "отказ в

обслуживании".
DoS-атака или Denial of Service attack — это атака типа «отказ в обслуживании».
Суть этого типа атак состоит в «перегрузке» атакуемого сервера или каналов связи, а
исчерпание ресурсов атакуемой системы или ухудшает качество работы приложения,
или вообще прекращает его работу. Простой DoS встречается редко и обычно
отбивается банальной блокировкой доступа к системе для атакующего компьютера.
DDоS — это распределённая атака, основанная на том же принципе, то есть
производящаяся с более чем одного атакующего компьютера. DDoS несколько
усложняет блокировку атакующих — чем больше атакующий ботнет, тем сложнее
отбиваться.
DDoS — это не про HighLoad или производительность.DoS или DDoS не стоит
путать с падением производительности или сбоями под нагрузкой.
Начнём с того, что 9 из 10 случаев, когда Заказчик говорит, что его проект DDoS'ят —
это заблуждение, вызванное тем, что сайт просто «тормозит» по другим причинам:
плохая архитектура приложения или недостаточно мощное хостинговое
оборудование.
● Реальный DDoS стоит для его инициатора денег и редко длится неделями, как
это бывает у «заблуждающихся».
● В принципе не DDoS'ят «местячковые» проекты, которые посещает не больше
несколько сотен человек в сутки — они просто никому «дорогу не переходят».
● Если сайт на дешевом виртуальном хостинге, то там и легитимные посетители
способны «положить» инфраструктуру.
● Проекты, сделанные дёшево и «на коленке», могут просто плохо работать, для
высокой производительности нужны усилия разработчиков, решения «из
коробки» редко бывают устойчивыми к нагрузкам.
Решение очень простое — сменить хостинг на более производительный, осуществить
профилирование работы сайта или веб-приложения и убрать «узкие места».
Реальные атаки DDoS
Если классифицировать по уровню атаки, то есть 2 сценария:
● (D)DoS на приложение
● (D)DoS на сеть
В случае, когда имеет место реальный (D)DoS, распространены два основных
варианта:
1. Атака относительно слабая и нацелена в основном на уровень приложения, но
приложение или сервер не могут от неё отбиться в силу недостаточной
оптимизированности. Это наиболее частый вариант, когда атака имеет место
на не самые популярные ресурсы. Чаще всего помогает настройка
брандмауэра, выявление и бан атакующих, а если проблема в приложении —
то спасает настройка кеширования и усложнение доступа к «тяжёлой»
функциональности, которая грузит сервер.
2. Атака сильная и полностью «забивает» канал связи — на уровне приложения и
сервера с ней уже не справиться. Встречается в коммерческом сегменте такое
не очень часто. Тут уже надо обращаться за помощью к хостеру или к
специализированным компаниям — они могут «взять удар на себя» и пропустят
к сайту только нормальных пользователей.
(D)DoS на приложение
Атака основана на отправке большого количества запросов на выполнение
ресурсоемких операций:
● большие выборки объектов без лимитов
● сложные фильтры / поиск
● запросы на обработку графики
● загрузка объемных файлов
Также можно классифицировать атаки по ресурсу, который подвергается наибольшей
нагрузке:
● CPU — процессор перегружен вычислениями
● RAM — не хватает оперативной памяти
 ● I/O — не хватает производительности ввода-вывода
● Хранилище — забивается система хранения
Основные механики защиты от DDos на уровень приложения:
● Настройка мониторинга показателей
● Выявление и анализ ресурсоемких запросов
● Оптимизация производительности
● Настройка кэширования
● Установка лимитов
● Использование очередей
● Требование аутентификации для «тяжелых» операций
● Проверка на человечность (капчи и подобные механизмы)
● Блокировка по IP
● Корректное конфигурирование серверного ПО под ресурсы (исключаем OOM)
● Возможность отключения вторичного функционала без ущерба для
работоспособности всей системы
(D)DoS на сеть
Принцип атаки: переполнение полосы пропускания, различный флуд (HTTP, ICMP,
UPD, SYN)
Основные механики защиты от DDos на уровень сети:
● Своевременное обновление ПО
● Конфигурация ядра ОС для поддержки большого количества соединений
● Брандмауэры / Firewalls
● Deep Packet Inspection (DPI)
● Услуги хостинг-провайдера
● Сервисы защиты / CDN

Объемные атаки (Volumetric attacks)

Объемные атаки или флуд. Самый распространённый тип. Злоумышленники делают
такое количество запросов к серверу, что образовавшийся трафик просто перекрывает
всю пропускную способность сети. Его объем может доходить до нескольких терабит в
секунду. В результате, неподготовленная инфраструктура не выдерживает атаки и
перестаёт отвечать на запросы.
К типу volumetric attacks относятся такие категории, как, например:
● DNS amplification (усиление). Суть атаки заключается в комбинации двух
вредоносных факторов. Во-первых, имитируя запрос с сервера жертвы путём
подстановки его IP в запрос, атакующий использует публичный DNS-сервер как
рефлектор, то есть, "отражатель". Тот, получив запрос якобы от атакуемого
сервера, возвращает ответ ему же, "отражая" запрос. Более того, запросить
можно не только IP-адрес домена, а намного больше данных, в связи с чем
ответ DNS-сервера станет гораздо более объемным. Наконец, трафик можно
довести до предела, осуществляя запросы через ботнет. Таким образом, с
высокой вероятностью достигается перегрузка пропускной полосы сервера
жертвы. Самый известный случай применения DNS reflected amplification —
атака на github в феврале 2018 — самая крупная из известных DDoS-атак.
Поток трафика достигал 1,35 Тб/с, а коэффициент усиления (амплификация) —
51 000.
 ● DNS flood — отправка запросов DNS-серверу с многочисленных IP-адресов.
Среди полученных сервером пакетов весьма тяжело обнаружить вредоносные.
● ICMP flood — ICMP пакеты не требуют подтверждения о получении, поэтому их
крайне трудно отделить от вредоносного трафика.
● SYN flood — отправка избыточного количества запросов на открытие новых
сессий с целью исчерпать память таблицы соединений. Стандартное
соединение с сервером по протоколу TCP производится методом трех
рукопожатий. На первом этапе клиент отправляет пакет с флагом SYN для
синхронизации. Сервер отвечает пакетом SYN-ACK, уведомляя клиента о
получении первого пакета и предлагая отправить завершающий, третий, для
подтверждения соединения. Клиент же не отвечает пакетом ACK, продолжая
флуд, и, тем самым, перегружая ресурсы сервера. SYN flood атакам, а также их
близким аналогам подвергались крупнейшие компании, такие как Amazon,
SoftLayer (IBM), Eurobet Italia SRL, Korea Telecom. Одним из серьезных
инцидентов стало выведение из строя сайта спортивных ставок Eurobet в
октябре 2019. Позднее в том же месяце жертвами TCP SYN-ACK reflection
стали ряд финансовых и телекоммуникационных компаний в Италии, Южной
Корее и Турции.

Атаки протокола (Protocol attacks)

Одной из самых распространенных киберугроз являются DDoS-атаки, Distributed Denial
of Service. Их целью является дословно "Отказ в обслуживании" — то есть такие атаки
нарушают работу серверов, сайтов, сервисов посредством избыточного потока
запросов. Не рассчитанные на высокие нагрузки ресурсы просто перестают работать,
в результате чего доступа к ним лишаются все пользователи. Также в рамках DDoS-
атак используются уязвимости на уровне сетевых протоколов и непосредственно
приложений.
Protocol attacks
Существует разновидность атак, в которых используются уязвимости сетевых
протоколов, таких как TCP, UDP, ICMP — 3 и 4 уровни модели OSI. В данном случае
стоит задача перегрузить сетевые мощности не столько гигантским объемом трафика,
сколько точечными действиями, использующими несовершенства сети. В частности, к
атакам данного типа относится:
● POD (ping of death) — пинг сервера с помощью ICMP пакетов, в которых
содержимое искажено или объем которых превышает максимально допустимый
Этот тип атаки потребляет фактические ресурсы сервера или промежуточного
коммуникационного оборудования, такого как межсетевые экраны и балансировщики
нагрузки, и измеряется в пакетах в секунду (Pps).

Атаки уровня приложения (Application layer

attacks)
Атаки на прикладном уровне, 7 уровень OSI, направлены на веб-сервера и
приложения — например, CMS сайта. Главной целью в данном случае является
выведение из строя ресурсов. В частности, чрезмерная нагрузка на CPU или RAM.
Цель может быть достигнута с помощью внешнего HTTP-запроса, в ответ на который
система начинает исполнение такого числа внутренних запросов, на которое просто не
рассчитана. К атакам на уровне приложений среди прочих относятся:
● HTTP flood — избыточное количество GET и POST запросов к серверу —
например, для получения самых тяжёлых элементов сайта. В данном случае на
сервер отправляется непрерывный поток GET и POST запросов, легитимных на
первый взгляд. Проблема в том, что атакующий не дожидается ответов, а
направляет запросы постоянно, вследствие чего ресурсы сервера
исчерпываются в процессе их обработки. Согласно открытым источникам, от
подобной атаки в ноябре 2016 пострадали сайты ряда крупных российских
банков. HTTP flood использовали в самом начале, чтобы точно определить
частоту запросов и объем трафика, необходимый для отказа в обслуживании.
Метод выступил как вспомогательный, после чего в ход пошли другие
инструменты.
● Slowloris — бот открывает множество сессий на сервере, при этом, не отвечая
на них и провоцируя таймаут. В результате, такие поддельные сессии забирают
на себя ресурсы сервера и ведут к его недоступности. Session attack или
Slowloris нацелена на "изматывание" сервера жертвы. Злоумышленник
открывает множество соединений и держит каждое из них открытым как можно
дольше до момента таймаута. Подобные атаки нелегко обнаружить, так как
соединение TCP уже установлено, HTTP запросы выглядят легитимными.
Через некоторое время такая тактика позволяет занять все соединения,
исключив доступ реальных пользователей к серверу. Slowloris приобрела
широкую известность в ходе президентских выборов в Иране, когда атакующие
предприняли попытку отключить сайты, принадлежащие правительству страны.

Уровни протоколов
Сетевой протокол - это набор правил, позволяющий осуществлять соединение и
обмен данными между двумя и более включенными в сеть компьютерами.Фактически
разные протоколы зачастую описывают лишь разные стороны одного типа связи;
взятые вместе, они образуют так называемый стек протоколов. Названия "протокол" и
"стек протоколов" также указывают и на программное обеспечение, которым
реализуется протокол.
Уровни протоколов
Наиболее распространённой системой классификации сетевых протоколов является
так называемая модель OSI. В соответствии с ней протоколы делятся на 7 уровней по
своему назначению - от физического (формирование и распознавание электрических
или других сигналов) до прикладного (API для передачи информации приложениями):
● Прикладной уровень, Application layer - Верхний (7-й) уровень модели,
обеспечивает взаимодействие сети и пользователя. Уровень разрешает
приложениям пользователя доступ к сетевым службам, таким как обработчик
запросов к базам данных, доступ к файлам, пересылке электронной почты.
Также отвечает за передачу служебной информации, предоставляет
приложениям информацию об ошибках и формирует запросы к уровню
представления. Пример: HTTP, POP3, SMTP.
● Уровень представления, Presentation layer - 6-й уровень отвечает за
преобразование протоколов и кодирование/декодирование данных. Запросы
приложений, полученные с уровня приложений, он преобразует в формат для
 передачи по сети, а полученные из сети данные преобразует в формат,
понятный приложениям. На уровне представления может осуществляться
сжатие/распаковка или кодирование/декодирование данных, а также
перенаправление запросов другому сетевому ресурсу, если они не могут быть
обработаны локально.
● Сеансовый уровень, Session layer - 5-й уровень модели отвечает за
поддержание сеанса связи, что позволяет приложениям взаимодействовать
между собой длительное время. Сеансовый уровень управляет
созданием/завершением сеанса, обменом информацией, синхронизацией
задач, определением права на передачу данных и поддержанием сеанса в
периоды неактивности приложений. Синхронизация передачи обеспечивается
помещением в поток данных контрольных точек, начиная с которых
возобновляется процесс при нарушении взаимодействия.
● Транспортный уровень, Transport layer - 4-й уровень модели, предназначен для
доставки данных без ошибок, потерь и дублирования в той
последовательности, как они были переданы. При этом неважно, какие данные
передаются, откуда и куда, то есть он предоставляет сам механизм передачи.
Блоки данных он разделяет на фрагменты, размер которых зависит от
протокола, короткие объединяет в один, а длинные разбивает. Протоколы этого
уровня предназначены для взаимодействия типа точка-точка. Пример: TCP,
UDP.
● Сетевой уровень, Network layer - 3-й уровень сетевой модели OSI,
предназначен для определения пути передачи данных. Отвечает за
трансляцию логических адресов и имён в физические, определение кратчайших
маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и заторов
в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.
● Канальный уровень, Data Link layer - этот уровень предназначен для
обеспечения взаимодействия сетей на физическом уровне и контроля за
ошибками, которые могут возникнуть. Данные, полученные с физического
уровня, он упаковывает во фреймы, проверяет на целостность, если нужно
исправляет ошибки и отправляет на сетевой уровень. Канальный уровень
может взаимодействовать с одним или несколькими физическими уровнями,
контролируя и управляя этим взаимодействием. Спецификация IEEE 802
разделяет этот уровень на 2 подуровня - MAC (Media Access Control)
регулирует доступ к разделяемой физической среде, LLC (Logical Link Control)
обеспечивает обслуживание сетевого уровня. На этом уровне работают
коммутаторы, мосты. В программировании этот уровень представляет драйвер
сетевой платы, в операционных системах имеется программный интерфейс
взаимодействия канального и сетевого уровней между собой, это не новый
уровень, а просто реализация модели для конкретной ОС. Примеры таких
интерфейсов: ODI, NDIS.
● Физический уровень, Physical layer - самый нижний уровень модели,
предназначен непосредственно для передачи потока данных. Осуществляет
передачу электрических или оптических сигналов в кабель или в радиоэфир и
соответственно их приём и преобразование в биты данных в соответствии с
методами кодирования цифровых сигналов. Другими словами, осуществляет
интерфейс между сетевым носителем и сетевым устройством. На этом уровне
работают концентраторы (хабы), повторители (ретрансляторы) сигнала и
медиаконвертеры. Функции физического уровня реализуются на всех
 устройствах, подключенных к сети. Со стороны компьютера функции
физического уровня выполняются сетевым адаптером или последовательным
портом.
В основном используются протокол TCP/IP
Определение:
Transmission Control Protocol/Internet Protocol, TCP/IP (Протокол управления
передачей/Протокол Интернета)
Большинство операционных систем сетевых серверов и рабочих станций
поддерживает TCP/IP, в том числе серверы NetWare, все системы Windows, UNIX,
последние версии Mac OS, системы OpenMVS и z/OS компании IBM, а также
OpenVMS компании DEC. Кроме того, производители сетевого оборудования
создают собственное системное программное обеспечение для TCP/IP, включая
средства повышения производительности устройств. Стек TCP/IP изначально
применялся на UNIX-системах, а затем быстро распространился на многие другие
типы сетей.
Протоколы локальных сетей
● IPX/SPX;
● NetBEUI;
● AppleTalk;
● TCP/IP;
● SNA;
● DLC;
● DNA;
Свойства протоколов локальной сети
В основном протоколы локальных сетей имеют такие же свойства, как и Другие
коммуникационные протоколы, однако некоторые из них были разработаны давно, при
создании первых сетей, которые работали медленно, были ненадежными и более
подверженными электромагнитным и радиопомехам. Поэтому для современных
коммуникаций некоторые протоколы не вполне пригодны. К недостаткам таких
протоколов относится слабая защита от ошибок или избыточный сетевой трафик.
Кроме того, определенные протоколы были созданы для небольших локальных сетей
и задолго до появления современных корпоративных сетей с развитыми средствами
маршрутизации.
Протоколы локальных сетей должны иметь следующие основные характеристики:
● обеспечивать надежность сетевых каналов;
● обладать высоким быстродействием;
● обрабатывать исходные и целевые адреса узлов;
● соответствовать сетевым стандартам, в особенности - стандарту IEEE 802.
Понятие протокола Интернет
Очевидно, что рано или поздно компьютеры, расположенные в разных точках земного
шара, по мере увеличения своего количества должны были обрести некие средства
общения. Такими средствами стали компьютерные сети. Сети бывают локальными и
глобальными. Локальная сеть - это сеть, объединяющая компьютеры, географически
расположенные на небольшом расстоянии друг от друга - например, в одном здании.
Глобальные сети служат для соединения сетей и компьютеров, которых разделяют
большие расстояния - в сотни и тысячи километров. Интернет относится к классу
глобальных сетей.
Простое подключение одного компьютера к другому - шаг, необходимый для создания
сети, но не достаточный. Чтобы начать передавать информацию, нужно убедиться,
что компьютеры "понимают" друг друга. Как же компьютеры "общаются" по сети?
Чтобы обеспечить эту возможность, были разработаны специальные средства,
получившие название "протоколы". Протокол - это совокупность правил, в
соответствии с которыми происходит передача информации через сеть. Понятие
протокола применимо не только к компьютерной индустрии. Даже те, кто никогда не
имел дела с Интернетом, скорее всего работали в повседневной жизни с какими-либо
устройствами, функционирование которых основано на использовании протоколов.
Так, обычная телефонная сеть общего пользования тоже имеет свой протокол,
который позволяет аппаратам, например, устанавливать факт снятия трубки на другом
конце линии или распознавать сигнал о разъединении и даже номер звонящего.
Исходя из этой естественной необходимости, миру компьютеров потребовался единый
язык (то есть протокол), который был бы понятен каждому из них.
Основные протоколы Интернет:
● TCP/IP
● POP3
● SMTP
● FTP
● HTTP
● IMAP4
● WAIS
● Gorpher
● WAP

Возможности защиты от атак DDoS. Что

анализируется?
Очевидно, что кибербезопасность — узкая компетенция и её едва ли удастся закрыть
так же легко, как HR или бухгалтерию, какой бы продвинутой ни была компания. Важно
заботиться о том, чтобы ваши сервис-провайдеры и поставщики инфраструктуры были
глубоко погружены в вопросы кибербезопасности и зарекомендовали себя как
настоящие профессионалы.
Надёжная защита обеспечивается соблюдением 3 условий:
● Использование проверенного решения для непрерывной защиты от DDoS-атак;
● Разработка плана действий на случай угрозы — DDoS Response Plan;
● Проведение регулярного healthcheck системы и устранение уязвимостей
приложений.
Если рассматривать облачную инфраструктуру, то в данной сфере защита требует
особого внимания.
Сервер — одна из основ любого веб-сервиса, приложения, сайта. Если на него
совершена атака, которая привела к потере доступа пользователей к ресурсам,
последствия могут быть плачевными. Это финансовые и репутационные риски,
компрометация конфиденциальной информации, уничтожение ценных ресурсов,
судебные риски.
Чтобы сохранить активы в безопасности, важно использовать проверенные средства
онлайн-защиты. Они должны включать такие элементы, как:
 ● Средства непрерывного мониторинга трафика и выявления подозрительной
активности;
● Black- и whitelisting IP-адресов;
● Систему оповещения об угрозах;
● Систему нейтрализации атак.
Особенно важно в процессе ликвидации угрозы не заблокировать пользовательский
трафик вместе с вредоносным.
Показательным примером эффективной точной настройки служит сервис защиты от
DDoS-атак компании G-Core Labs. Этот сервис полезен любому онлайн-бизнесу:
медиа-ресурсам, разработчикам и издателям игр, телеком-компаниям, страховому
бизнесу и банкам, а особенно — интернет-магазинам.
Интеллектуальная фильтрация трафика на основе анализа статистических,
сигнатурных, технических и поведенческих факторов дает возможность блокировать
даже единичные вредоносные запросы, не затрагивая рядовых пользователей.
DDoS Response Plan
План реагирования призван ограничить ущерб, причиняемый DDoS-атакой. Это
должна быть чёткая последовательность действий и мер, незамедлительно
принимаемых при возникновении угрозы.
Подробный план должен включать, как минимум, такие меры, как:
● Установление полного перечня ресурсов, подвергшихся атаке;
● Локализация угрозы и предотвращение её распространения;
● Оповещение ответственных и заинтересованных лиц об инциденте;
● Идентификация характера угрозы, обнаружение цифровых следов;
● Определение методов и средств, лежащих в основе атаки;
● Полное сканирование IT-инфраструктуры, оценка ущерба;
● Контроль исходящего трафика и предотвращение утечек информации;
● Устранение угрозы;
● Подготовка к противодействию аналогичным атакам в будущем.
Регулярный Healthcheck системы и устранение уязвимостей приложения
Чтобы DDoS-атака не застала врасплох и нанесла минимальный урон, следует
постоянно совершенствовать защитные механизмы. Правило касается не только
инструментов, предназначенных для отражения атак, но и защищаемой
инфраструктуры и приложения.
Сканирование систем на предмет уязвимостей и постоянное обновление кода
приложений поможет поддерживать устойчивость ресурсов компании к большинству
известных киберугроз.
Всё это перечень потенциальных угроз:
● Уязвимости на этапе аутентификации;
● Вредоносные вставки кода;
● Cross-site scripting;
● Уязвимости шифрования;
● Логические ошибки, несовершенная структура данных;
Как определить оптимальность модель для
бизнеса (фирмы) (IaaS, SaaS, PaaS)?
Об облаках, облачных технологиях и виртуализации говорят уже долго, особенно о
трех наиболее популярных моделях обслуживания: программное обеспечение как
услуга (SaaS), платформа как услуга (PaaS) и инфраструктура как услуга (IaaS).
Стек облачных технологий состоит из трех частей, каждая из которых представляет
отдельную категорию сервисов.
На верхнем уровне располагается SaaS — по сути, это облачные приложения, доступ
к которым предоставляется через веб-интерфейс.
За ним следует PaaS — платформа для самостоятельной разработки и
развертывания приложений.
На третьем уровне расположился IaaS — серверы, хранилища, сети, вычислительная
инфраструктура, которую клиент получает в пользование для запуска своих решений.
Для демонстрации этих трех типов услуг часто применяется аналогия с пиццей —
своеобразная «Pizza as a Service». Когда потребитель заказывает и поедает пиццу в
кафе или ресторане, то это SaaS, а если заказывает её себе на дом, то это PaaS.
Если же он пошел в магазин, купил ингредиентов и приготовил блюдо самостоятельно,
то, можно сказать, что это IaaS.
Что такое IaaS
При выборе IaaS вы получите серверы, сетевые ресурсы и хранилища в качестве
подключаемой услуги. Получается, что компания приобретает вычислительные
ресурсы у поставщика, избегая необходимости закупать собственное железо и
поддерживать его. При этом сервис может быть предоставлен по типу публичного
облака, частного облака или комбинированного подхода.
Понятие IaaS включает в себя следующие особенности:
● Ресурсы — это услуга. Клиент имеет возможность в любое время увеличивать
и уменьшать объемы потребляемых ресурсов
● С физическими ресурсами могут работать несколько пользователей благодаря
возможностям виртуализации
● Гибкие модели оплаты (например, вариант pay as you go, когда компания
платит только за потребляемые мощности)
Учитывая все вышесказанное, можно определить, когда следует использовать IaaS-
решения. Обращаться к IaaS стоит в том случае, компания иногда испытывает нужду в
повышении мощностей при всплесках нагрузки — то есть имеется потребность в
оперативном масштабировании инфраструктуры.
Еще один вариант — компания представляет собой стартап, у которого нет средств на
приобретение собственного «железа» и его поддержание, или же организация хочет
запустить экспериментальное направление бизнеса и закупать оборудование для
этого не всегда бывает целесообразно (проект может не взлететь).
Однако несмотря на гибкость и масштабируемость IaaS, технология имеет
определенные ограничения. В связи с этим есть ситуации, когда использовать ее не
рекомендуется. Например, компания является игроком регулируемой отрасли,
правила которой не разрешают хранение данных на серверах, не принадлежащих
компании.
Что такое PaaS
Платформа как услуга, или PaaS, упрощает развертку приложений и управление ими,
при этом скрывая внутри себя работу с серверами, балансировку нагрузки, DNS и др.
Поэтому отпадает необходимость нанимать инженеров для обслуживания
инфраструктуры. Это позволяет разработчикам уделять больше внимания разработке
и проблемам развертывания.
Здесь следует отметить, поскольку PaaS является вторым уровнем пирамиды
облачных услуг, то он строится на основе IaaS, однако еще сильнее уменьшает время
с момента генерации идеи до её воплощения. Это достигается за счет большей
автоматизации процессов и абстракции от железа.
Чтобы абстрагировать концепцию работы с серверами, было проделано следующее:
● Реализована система сборки, компилирующая и хранящая код;
● Внедрена база данных управления приложениями, следящая за версиями и
метаданными;
● Запущен планировщик заданий, обрабатывающий большую группу серверов и
запускающий приложение на нескольких машинах как на одной;
● Балансировщик нагрузки управляет интернет-трафиком;
● Работа DNS автоматизирована;
● Реализована форма контейнеризации (FreeBSD Jail, Solaris Zones, Linux
Containers), предотвращающая вмешательство одного приложения в работу
другого.
Первый и последний пункты — это те элементы, которые способствовали росту
популярности Docker. Технология Linux Container давно являлась частью ядра ОС
Linux, но автоматизировать их использование решились только крупные компании или
PaaS-провайдеры.
Компании используют архитектуры и микросервисы, ориентированные на работу с
программным обеспечением, потому что они предлагают возможности по
автоматическому развертыванию и тестированию кода, а также масштабирования в
зависимости от нагрузки. Этот функционал и реализует PaaS.
К сожалению, такой подход имеет один серьезный недостаток. Вы передаете часть
контроля своеобразному черному ящику и попадаете в зависимость от него. Однако в
противном случае компании постоянно заново изобретают велосипед или начинают
использовать медленные инструменты.
Что такое SaaS
В случае SaaS потребитель приобретает возможность пользоваться приложениями
поставщика, выполняемыми в облаке. Приложения доступны с различных клиентских
устройств, например через браузер.
Программное обеспечение как услуга (SaaS) — последний уровень облачных
вычислений, который чаще всего дополняет PaaS, как видно из схемы в начале
статьи. Это полнофункциональное приложение для пользователя, выполняющее
определенные функции — например работу с изображениями или звуком. Наиболее
популярной формой оплаты в этом сегменте остается подписка.
В случае SaaS в зону ответственности облачного провайдера передаются вопросы
настройки приложений, мониторинга и резервного копирования. Поэтому такая модель
работы не требует наличия в команде организации технического специалиста — все
делает провайдер.
Таким образом, чем более высокоуровневую модель вы планируете
использовать, тем меньший уровень компетенций в ИТ требуется от команды.
Справедливо и обратное — чем ниже уровень ИТ-зрелости вашей компании, тем
более высокоуровневая модель вам потребуется.