[{"data":1,"prerenderedAt":721},["ShallowReactive",2],{"topic:aidt-bac-cloud_tech:topic-01":3},{"content":4,"pz":340,"lr":352,"additional":340,"courseMeta":677},{"id":5,"title":6,"body":7,"course_slug":339,"description":17,"env_label":340,"env_url":340,"extension":341,"group":340,"is_course_project":342,"is_index":342,"level":340,"meta":343,"navigation":344,"path":345,"section":346,"seo":347,"stem":348,"topic_number":349,"topic_slug":350,"__hash__":351},"courses\u002Fcourses\u002Faidt-bac-cloud_tech\u002Ftopic-01-content.md","Основы облачных технологий",{"type":8,"value":9,"toc":311},"minimark",[10,14,18,21,24,29,34,37,40,43,47,50,53,56,59,62,65,77,80,84,87,90,93,96,100,103,107,110,113,116,120,123,126,129,133,136,139,142,146,149,157,160,163,167,170,174,177,180,183,187,190,193,196,200,203,206,209,213,221,224,228,231,235,238,241,249,252,256,259,267,270,273,277,280,283,286,289,292,296,299,302,305,308],[11,12,6],"h1",{"id":13},"основы-облачных-технологий",[15,16,17],"p",{},"На протяжении нескольких десятилетий вычислительная инфраструктура организаций строилась преимущественно на локальных ресурсах. Серверы размещались в собственных или арендованных помещениях, закупались с запасом на пиковые нагрузки, требовали физического обслуживания и планирования замены оборудования. Такая модель обеспечивала полный контроль над средой, но порождала целый ряд устойчивых проблем: длительные сроки ввода мощностей в эксплуатацию, низкий средний коэффициент использования оборудования и необходимость содержать штат специалистов для обслуживания физической инфраструктуры.",[15,19,20],{},"Облачные вычисления представляют собой принципиально иной подход к организации доступа к вычислительным ресурсам. Вместо приобретения и сопровождения оборудования потребитель получает ресурсы по запросу через сеть, оплачивая фактическое потребление. Эта модель изменяет не только экономику владения инфраструктурой, но и способ проектирования, развертывания и сопровождения программных систем. Поэтому понимание основ облачной модели является обязательной предпосылкой для дальнейшего изучения виртуализации, контейнеризации и оркестрации, составляющих технологическое ядро данного курса.",[15,22,23],{},"Настоящая тема раскрывает фундаментальные понятия облачных вычислений: сущность облачной модели и её ключевые признаки, модели предоставления сервисов, модели развертывания инфраструктуры, а также экономические и эксплуатационные эффекты, определяющие практический смысл перехода к облаку. Каждый из этих вопросов рассматривается не только в описательном ключе, но и с позиции ограничений, допущений и типичных ошибок интерпретации, которые возникают при первом знакомстве с облачной тематикой.",[25,26,28],"h2",{"id":27},"сущность-облачной-модели-вычислений","Сущность облачной модели вычислений",[30,31,33],"h3",{"id":32},"переход-от-локальной-инфраструктуры-к-модели-предоставления-ресурсов-по-запросу","Переход от локальной инфраструктуры к модели предоставления ресурсов по запросу",[15,35,36],{},"Традиционная модель организации вычислительной инфраструктуры предполагает, что организация самостоятельно приобретает, размещает и обслуживает аппаратные ресурсы. Сервер, закупленный для конкретного проекта, физически устанавливается в серверном помещении или центре обработки данных (ЦОД), подключается к сети, настраивается, а затем эксплуатируется на протяжении нескольких лет до момента замены. Этот подход принято обозначать термином «on-premises» (локальное размещение). Его ключевая особенность состоит в том, что ответственность за все уровни инфраструктуры — от электропитания до прикладного программного обеспечения — лежит на самой организации.",[15,38,39],{},"Облачная модель вычислений меняет этот принцип. Вычислительные, сетевые и дисковые ресурсы предоставляются сторонним поставщиком через программный интерфейс или веб-консоль. Потребитель не владеет оборудованием, не отвечает за его физическое размещение и не планирует его жизненный цикл. Вместо этого он формулирует требования к ресурсам, получает их в необходимом объёме и освобождает по мере завершения потребности. Такая модель делает вычислительные ресурсы аналогичными коммунальным услугам: они доступны по требованию, потребляются в необходимом количестве и оплачиваются по факту использования.",[15,41,42],{},"Важно подчеркнуть, что переход к облаку не сводится к замене физического оборудования виртуальным. Облачная модель меняет саму логику взаимодействия с инфраструктурой. Если при локальном размещении решение о приобретении ресурсов принимается заблаговременно, с учётом прогнозируемой нагрузки, то в облачной среде ресурсы могут быть получены в момент возникновения потребности и возвращены сразу после её удовлетворения. Это различие имеет не только экономические, но и архитектурные следствия: приложения могут проектироваться с расчётом на динамическое изменение объёма доступных ресурсов, а не на фиксированную аппаратную конфигурацию.",[30,44,46],{"id":45},"ключевые-признаки-облачной-среды","Ключевые признаки облачной среды",[15,48,49],{},"Для формального определения облачных вычислений в мировой практике принято опираться на характеристики, сформулированные Национальным институтом стандартов и технологий США (National Institute of Standards and Technology, NIST). Согласно этому определению, облачная среда обладает пятью существенными признаками.",[15,51,52],{},"Первый признак — самообслуживание по требованию (on-demand self-service). Потребитель может самостоятельно выделять вычислительные ресурсы — серверные мощности, хранилища, сетевые компоненты — без необходимости обращения к представителю поставщика. Это означает, что процесс предоставления ресурсов автоматизирован и доступен через программный интерфейс или панель управления.",[15,54,55],{},"Второй признак — широкая сетевая доступность (broad network access). Облачные ресурсы доступны через сеть с использованием стандартных протоколов и механизмов доступа. Это позволяет потребителям работать с инфраструктурой из различных сред: рабочих станций, мобильных устройств, удалённых терминалов.",[15,57,58],{},"Третий признак — объединение ресурсов (resource pooling). Поставщик объединяет физические ресурсы в общий пул и динамически распределяет их между несколькими потребителями. Конкретный потребитель, как правило, не контролирует и не знает точного физического расположения предоставленных ему ресурсов, хотя может задать ограничения на уровне региона или зоны доступности.",[15,60,61],{},"Четвёртый признак — быстрая эластичность (rapid elasticity). Ресурсы могут масштабироваться — увеличиваться или уменьшаться — в соответствии с текущими потребностями потребителя. С точки зрения пользователя доступные ресурсы кажутся практически неограниченными и могут быть получены в любом объёме в любой момент.",[15,63,64],{},"Пятый признак — измеряемость потребления (measured service). Облачная система автоматически контролирует и оптимизирует использование ресурсов, предоставляя механизмы мониторинга, отчётности и прозрачного учёта потребления. Это обеспечивает возможность оплаты строго за использованные ресурсы и позволяет обеим сторонам — поставщику и потребителю — контролировать объём предоставленных услуг.",[66,67,68,69,68,74],"figure",{},"\n  ",[70,71],"img",{"src":72,"alt":73},"\u002Fimg\u002Faidt-bac-cloud_tech\u002Ftopic-01\u002Fnist_cloud_characteristics.svg","Пять существенных признаков облачной среды по NIST",[75,76,73],"figcaption",{},[15,78,79],{},"Следует оговориться, что перечисленные признаки описывают идеальную модель. На практике конкретные облачные платформы могут реализовывать эти свойства в различной степени. Например, эластичность может быть ограничена квотами, время выделения ресурсов может составлять не секунды, а минуты, а механизмы учёта потребления могут существенно различаться по прозрачности и детализации. Тем не менее именно совокупность этих пяти признаков позволяет отличить облачную среду от традиционного хостинга или обычной аренды виртуальных серверов, где степень автоматизации и эластичности существенно ниже.",[30,81,83],{"id":82},"отличие-облачных-вычислений-от-традиционного-хостинга-и-классической-серверной-инфраструктуры","Отличие облачных вычислений от традиционного хостинга и классической серверной инфраструктуры",[15,85,86],{},"Разграничение облачных вычислений и традиционного хостинга важно не только терминологически, но и практически. Услуги традиционного хостинга — аренда выделенного сервера, виртуального сервера с фиксированной конфигурацией, размещение оборудования в ЦОД — существуют на рынке давно и продолжают использоваться. Однако они, как правило, не обладают свойствами эластичности и автоматического самообслуживания. Арендованный сервер предоставляется в заранее согласованной конфигурации, его масштабирование требует ручного вмешательства или нового договора, а управление осуществляется через ограниченный набор инструментов.",[15,88,89],{},"Облачная модель отличается тем, что инфраструктура программно определяема (software-defined). Это означает, что создание, конфигурирование, масштабирование и уничтожение ресурсов осуществляется через программный интерфейс (API), а не посредством физических операций или переговоров с поставщиком. Программная определяемость делает инфраструктуру пригодной для автоматизации: ресурсы могут создаваться и удаляться скриптами, описываться в конфигурационных файлах и управляться как часть программного проекта.",[15,91,92],{},"Ещё одно существенное отличие касается модели тарификации. Традиционный хостинг чаще всего предполагает фиксированную абонентскую плату за заранее определённый объём ресурсов, независимо от фактической загрузки. Облачная модель в типичном случае предполагает оплату по факту потребления (pay-as-you-go): потребитель платит за количество использованных процессорных часов, объём хранимых данных, объём переданного сетевого трафика. Это различие создаёт как преимущества, так и риски, которые подробнее рассматриваются в разделе об экономике облака.",[15,94,95],{},"Таким образом, облачные вычисления не следует воспринимать как простое продолжение услуг хостинга. Это качественно иная модель, в основе которой лежат программная определяемость, эластичность, автоматизированное управление и учёт потребления. Понимание этих различий необходимо для корректной оценки возможностей и ограничений облачной инфраструктуры.",[25,97,99],{"id":98},"модели-предоставления-сервисов","Модели предоставления сервисов",[15,101,102],{},"Облачная модель вычислений не является однородной. В зависимости от того, какой именно уровень инфраструктуры предоставляется потребителю в виде управляемого сервиса, принято различать несколько моделей обслуживания. Каждая из них определяет границу ответственности между поставщиком облачных услуг и потребителем: чем выше уровень абстракции сервиса, тем меньше задач ложится на потребителя и тем больше контроля он передаёт поставщику.",[30,104,106],{"id":105},"инфраструктура-как-услуга-infrastructure-as-a-service-iaas","Инфраструктура как услуга (Infrastructure as a Service, IaaS)",[15,108,109],{},"Модель IaaS предоставляет потребителю базовые вычислительные ресурсы: виртуальные машины, дисковые хранилища, сетевые компоненты. Потребитель получает доступ к виртуализированной инфраструктуре, на которой он самостоятельно устанавливает операционную систему, настраивает среду выполнения, развёртывает приложения и отвечает за их сопровождение. Поставщик при этом обеспечивает работоспособность физического оборудования, гипервизора, сетевой инфраструктуры и базовых служб платформы.",[15,111,112],{},"Граница ответственности в IaaS проходит на уровне операционной системы. Всё, что находится выше — системное администрирование, установка обновлений, настройка безопасности, развертывание приложений — является задачей потребителя. Это создаёт максимальную гибкость: потребитель может использовать любые операционные системы, любые программные стеки и любые конфигурации. Однако эта же гибкость порождает значительную эксплуатационную нагрузку, поскольку требует квалификации в области системного администрирования, сетевой безопасности и сопровождения инфраструктуры.",[15,114,115],{},"IaaS является наиболее близкой к традиционной серверной модели формой облачного сервиса. Потребитель работает с виртуальными машинами примерно так же, как с физическими серверами, но получает преимущества облачной модели: эластичность, автоматизируемость и оплату по факту потребления. Примерами IaaS-сервисов являются Amazon EC2, Google Compute Engine, Azure Virtual Machines, Yandex Compute Cloud.",[30,117,119],{"id":118},"платформа-как-услуга-platform-as-a-service-paas","Платформа как услуга (Platform as a Service, PaaS)",[15,121,122],{},"Модель PaaS поднимает уровень абстракции выше. Потребитель получает не виртуальную машину, а готовую платформу для развертывания приложений. Поставщик берёт на себя управление операционной системой, средой выполнения, базовыми службами и инфраструктурными компонентами. Потребитель сосредоточен на разработке, развертывании и сопровождении прикладного кода, не занимаясь вопросами конфигурации серверов и системного программного обеспечения.",[15,124,125],{},"Практический смысл PaaS состоит в сокращении эксплуатационной нагрузки. Разработчик загружает код приложения, а платформа обеспечивает его исполнение, масштабирование, балансировку нагрузки и базовый мониторинг. Это позволяет существенно ускорить цикл разработки и развертывания, особенно для типовых веб-приложений и сервисов. Однако у этой модели есть и ограничения. PaaS накладывает требования на архитектуру приложения: поддерживаемые языки программирования, среды выполнения, способы хранения данных и механизмы масштабирования определяются поставщиком платформы. Если приложение не вписывается в предложенные рамки, его адаптация может оказаться трудоёмкой или невозможной.",[15,127,128],{},"Ещё одним следствием модели PaaS является более выраженная зависимость от поставщика (vendor lock-in). Приложение, спроектированное под конкретную платформу, может использовать специфические интерфейсы, механизмы хранения и способы конфигурации, которые не переносятся напрямую на другие платформы. Поэтому выбор PaaS требует осознанной оценки баланса между удобством и степенью привязки. Примерами PaaS-сервисов являются Google App Engine, Heroku, Azure App Service.",[30,130,132],{"id":131},"программное-обеспечение-как-услуга-software-as-a-service-saas","Программное обеспечение как услуга (Software as a Service, SaaS)",[15,134,135],{},"Модель SaaS представляет собой наивысший уровень абстракции в классификации облачных сервисов. Потребитель получает доступ к готовому приложению, работающему в облачной инфраструктуре поставщика. Вся ответственность за инфраструктуру, платформу, среду выполнения и само приложение лежит на поставщике. Потребитель использует приложение через веб-интерфейс или API, не занимаясь ни его установкой, ни обновлением, ни обеспечением доступности.",[15,137,138],{},"SaaS является наиболее распространённой формой облачного потребления для конечных пользователей. Примеры SaaS-решений хорошо знакомы: почтовые сервисы, системы управления проектами, офисные пакеты, платформы для совместной работы. С точки зрения курса облачных технологий модель SaaS интересна прежде всего как граничный случай, демонстрирующий предельную степень передачи контроля поставщику. Потребитель SaaS не имеет доступа ни к инфраструктуре, ни к платформе, ни к исходному коду приложения. Его возможности ограничены конфигурацией, предусмотренной поставщиком.",[15,140,141],{},"Ограничения SaaS проявляются в невозможности глубокой настройки, в зависимости от политик поставщика в отношении хранения данных, доступности и функциональных обновлений, а также в риске потери доступа к данным при прекращении оказания услуги. Для инженерных задач, связанных с проектированием и эксплуатацией инфраструктуры, SaaS является объектом изучения, но не основным инструментом работы.",[30,143,145],{"id":144},"сравнение-моделей","Сравнение моделей",[15,147,148],{},"Три рассмотренные модели образуют спектр, на одном конце которого находится максимальный контроль при высокой эксплуатационной нагрузке (IaaS), а на другом — минимальный контроль при минимальной нагрузке (SaaS). PaaS занимает промежуточную позицию.",[66,150,68,151,68,155],{},[70,152],{"src":153,"alt":154},"\u002Fimg\u002Faidt-bac-cloud_tech\u002Ftopic-01\u002Fiaas_paas_saas_responsibility.svg","Распределение ответственности между потребителем и поставщиком в моделях On-Premises, IaaS, PaaS и SaaS",[75,156,154],{},[15,158,159],{},"Выбор модели определяется не абстрактными предпочтениями, а конкретными требованиями. Если организации необходимо полное управление операционной системой и сетевой конфигурацией, IaaS является единственным подходящим вариантом. Если задача сводится к быстрому развертыванию типового приложения, PaaS может оказаться более рациональным выбором. Если потребность состоит в использовании готового продукта без необходимости его сопровождения, SaaS удовлетворяет её наиболее полно.",[15,161,162],{},"Важно понимать, что границы между моделями не являются абсолютно жёсткими. Современные облачные платформы предлагают сервисы, которые сочетают признаки нескольких моделей. Например, управляемые базы данных предоставляют инфраструктурный ресурс (хранилище, вычисления), но освобождают потребителя от задач системного администрирования, что сближает их с PaaS. Управляемые сервисы оркестрации контейнеров (такие как Amazon EKS или Google GKE) располагаются на границе IaaS и PaaS. Поэтому классификация моделей полезна как концептуальная рамка, но не должна восприниматься как строгая таксономия с непроницаемыми границами.",[25,164,166],{"id":165},"модели-развертывания-облачной-инфраструктуры","Модели развертывания облачной инфраструктуры",[15,168,169],{},"Помимо модели предоставления сервисов, облачная инфраструктура различается по способу развертывания. Эта классификация отвечает на вопрос о том, кому принадлежит и кем эксплуатируется облачная среда, а также кто имеет к ней доступ. Выбор модели развертывания определяется требованиями к безопасности, нормативному соответствию, стоимости и масштабируемости.",[30,171,173],{"id":172},"публичное-облако-public-cloud","Публичное облако (public cloud)",[15,175,176],{},"Публичное облако представляет собой инфраструктуру, которая принадлежит и управляется сторонним поставщиком облачных услуг и предоставляется широкому кругу потребителей. Физические ресурсы являются общими для множества арендаторов (multi-tenancy), хотя каждый потребитель работает в логически изолированной среде. Публичное облако обеспечивает наибольшую эластичность и наименьшие начальные затраты, поскольку потребителю не требуется приобретать оборудование и содержать инфраструктуру.",[15,178,179],{},"К основным преимуществам публичного облака относятся практически неограниченная масштабируемость, глобальная географическая доступность, широкий спектр предоставляемых сервисов и модель оплаты по факту потребления. Крупнейшими поставщиками публичных облачных услуг являются Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), а также региональные провайдеры, такие как Yandex Cloud.",[15,181,182],{},"Вместе с тем публичное облако имеет ограничения. Потребитель не контролирует физическое расположение данных с точностью до конкретного сервера, не может влиять на политику обновления платформы и вынужден полагаться на гарантии поставщика в отношении доступности и безопасности. Для отдельных отраслей — финансового сектора, здравоохранения, государственного управления — нормативные требования могут ограничивать или полностью исключать размещение определённых категорий данных в публичном облаке.",[30,184,186],{"id":185},"частное-облако-private-cloud","Частное облако (private cloud)",[15,188,189],{},"Частное облако представляет собой облачную инфраструктуру, выделенную для использования одной организацией. Оно может размещаться как на собственных площадках организации, так и на площадках стороннего поставщика, но в обоих случаях ресурсы не разделяются с другими потребителями. Частное облако позволяет реализовать те же принципы — самообслуживание, эластичность, измеряемость, — но в контролируемой среде с более жёстким управлением доступом и политиками безопасности.",[15,191,192],{},"Мотивация к построению частного облака обычно связана с требованиями безопасности и нормативного соответствия. Организация сохраняет полный контроль над физическим расположением данных, сетевой инфраструктурой и политиками доступа. Это особенно важно в тех случаях, когда обрабатываемые данные подпадают под регуляторные ограничения, требующие их локализации или исключения доступа третьих лиц.",[15,194,195],{},"Однако частное облако имеет существенные ограничения. Построение и сопровождение такой инфраструктуры требует значительных капитальных вложений, квалифицированного персонала и непрерывных затрат на эксплуатацию. Масштабируемость частного облака ограничена объёмом имеющихся физических ресурсов: при исчерпании ёмкости необходимо закупать новое оборудование, что занимает время и требует дополнительных инвестиций. Поэтому частное облако, как правило, экономически оправдано для крупных организаций с устойчивыми и предсказуемыми нагрузками.",[30,197,199],{"id":198},"гибридное-облако-hybrid-cloud","Гибридное облако (hybrid cloud)",[15,201,202],{},"Гибридное облако объединяет элементы публичного и частного облака, обеспечивая возможность переноса нагрузок между ними. Типичный сценарий состоит в том, что базовая нагрузка обрабатывается в частном облаке, а пиковые запросы перенаправляются в публичное. Другой распространённый вариант предполагает размещение критически важных данных в частном облаке с использованием публичного облака для менее чувствительных задач.",[15,204,205],{},"Привлекательность гибридной модели состоит в возможности сочетать контроль частного облака с эластичностью публичного. Однако на практике реализация гибридного облака порождает значительные инженерные сложности. Необходимо обеспечить надёжную сетевую связность между средами, единообразные политики безопасности и управления доступом, совместимость форматов данных и механизмов развертывания. Переносимость нагрузок между частным и публичным сегментами требует продуманной архитектуры приложений и инфраструктуры, а не является свойством, возникающим автоматически.",[15,207,208],{},"Типичная ошибка при обсуждении гибридного облака состоит в предположении, что простое одновременное использование частной и публичной инфраструктуры уже образует гибридное облако. На самом деле гибридная модель предполагает интеграцию сред: оркестрацию нагрузок, единый контур управления, согласованные политики. Без этих элементов речь идёт о параллельном использовании двух разрозненных инфраструктур, а не о гибридном облаке в строгом смысле.",[30,210,212],{"id":211},"выбор-модели-развертывания","Выбор модели развертывания",[66,214,68,215,68,219],{},[70,216],{"src":217,"alt":218},"\u002Fimg\u002Faidt-bac-cloud_tech\u002Ftopic-01\u002Fcloud_deployment_models.svg","Модели развертывания облачной инфраструктуры: публичное, частное и гибридное облако",[75,220,218],{},[15,222,223],{},"Выбор между публичным, частным и гибридным облаком определяется совокупностью факторов: требованиями к безопасности и нормативному соответствию, характером нагрузок, бюджетными ограничениями, наличием квалифицированных кадров и стратегическими приоритетами организации. Универсального решения не существует. Публичное облако оптимально для стартапов, исследовательских проектов и нагрузок с высокой вариативностью. Частное облако подходит для организаций с жёсткими регуляторными требованиями и стабильной нагрузкой. Гибридное облако позволяет совместить достоинства обоих подходов, но требует зрелой инженерной практики и дополнительных затрат на интеграцию.",[25,225,227],{"id":226},"экономика-и-эксплуатационные-эффекты-облака","Экономика и эксплуатационные эффекты облака",[15,229,230],{},"Переход к облачной модели затрагивает не только техническую архитектуру, но и экономику владения инфраструктурой. Понимание экономических эффектов облака важно не менее, чем знание его технических характеристик, поскольку именно экономические соображения часто определяют решение о миграции в облако или отказе от неё.",[30,232,234],{"id":233},"капитальные-и-операционные-затраты","Капитальные и операционные затраты",[15,236,237],{},"В традиционной модели организация несёт капитальные затраты (Capital Expenditure, CapEx) на приобретение оборудования. Сервер приобретается единовременно, ставится на баланс и амортизируется в течение нескольких лет. Помимо стоимости самого оборудования, капитальные затраты включают расходы на проектирование серверного помещения, системы охлаждения, электроснабжения и физической безопасности. Эти расходы возникают до момента начала эксплуатации и не зависят от фактического уровня использования ресурсов.",[15,239,240],{},"Облачная модель трансформирует капитальные затраты в операционные (Operational Expenditure, OpEx). Потребитель не приобретает оборудование, а оплачивает использование ресурсов на регулярной основе. Это изменение имеет два важных следствия. Во-первых, снижается барьер входа: для запуска проекта не требуется крупных первоначальных инвестиций. Во-вторых, затраты становятся более пропорциональными реальному потреблению, что в теории позволяет избежать оплаты простаивающих ресурсов.",[66,242,68,243,68,247],{},[70,244],{"src":245,"alt":246},"\u002Fimg\u002Faidt-bac-cloud_tech\u002Ftopic-01\u002Fcapex_vs_opex.svg","Сравнение структуры затрат: традиционная модель (CapEx) и облачная модель (OpEx)",[75,248,246],{},[15,250,251],{},"Однако замена CapEx на OpEx не является безусловным преимуществом. При устойчивых и предсказуемых нагрузках облачное размещение может оказаться дороже, чем эксплуатация собственного оборудования. Это связано с тем, что в стоимость облачных ресурсов включена маржа поставщика, затраты на обеспечение избыточности и расходы на программную инфраструктуру платформы. Поэтому экономическая оценка облачной модели должна учитывать не только прямые затраты на ресурсы, но и полную стоимость владения (Total Cost of Ownership, TCO), включающую расходы на персонал, лицензии, сетевой трафик, хранение данных и обеспечение безопасности.",[30,253,255],{"id":254},"эластичное-выделение-ресурсов-как-инструмент-оптимизации-затрат","Эластичное выделение ресурсов как инструмент оптимизации затрат",[15,257,258],{},"Одним из центральных экономических преимуществ облака является эластичность — возможность динамически изменять объём потребляемых ресурсов в зависимости от текущей нагрузки. В традиционной модели оборудование закупается с расчётом на пиковые нагрузки. Если пиковая нагрузка составляет условные 100 единиц, а средняя — 30, то 70% ёмкости большую часть времени простаивает. Организация платит за полный объём оборудования вне зависимости от того, сколько из него используется.",[66,260,68,261,68,265],{},[70,262],{"src":263,"alt":264},"\u002Fimg\u002Faidt-bac-cloud_tech\u002Ftopic-01\u002Felasticity_resource_utilization.svg","Сравнение использования ресурсов: фиксированная ёмкость традиционной модели и эластичное выделение в облаке",[75,266,264],{},[15,268,269],{},"Эластичность облака позволяет приблизить фактическое потребление ресурсов к текущей потребности. В идеальном сценарии при нагрузке в 30 единиц потребитель оплачивает только 30 единиц, а при кратковременном росте до 100 единиц ресурсы масштабируются автоматически и возвращаются к прежнему уровню после снижения нагрузки. Это снижает избыточное резервирование и позволяет более рационально использовать бюджет.",[15,271,272],{},"На практике реализация эластичности требует инженерной подготовки. Приложение должно быть спроектировано таким образом, чтобы поддерживать горизонтальное масштабирование — добавление новых экземпляров обработки. Если архитектура приложения предполагает единственный сервер с фиксированным состоянием, эластичность облака не может быть использована в полной мере. Следовательно, эластичность является не только инфраструктурным свойством, но и архитектурным требованием к приложению.",[30,274,276],{"id":275},"риски-облачной-модели","Риски облачной модели",[15,278,279],{},"При всех преимуществах облачная модель несёт ряд рисков, которые должны учитываться при принятии решения о миграции.",[15,281,282],{},"Первый риск — неконтролируемый рост потребления. Простота выделения ресурсов в облаке может приводить к тому, что отдельные команды или проекты потребляют значительно больше, чем планировалось. Если в организации отсутствуют механизмы мониторинга и контроля расходов, общий счёт за облачные услуги может оказаться существенно выше ожидаемого. Эта проблема обозначается термином «cloud sprawl» (неконтролируемое разрастание облачных ресурсов).",[15,284,285],{},"Второй риск — зависимость от поставщика (vendor lock-in). Чем глубже организация интегрируется с конкретной облачной платформой, тем труднее перенести нагрузки на другую платформу или вернуть их в собственную инфраструктуру. Зависимость может проявляться на уровне специфических API, форматов данных, механизмов управления и ценовых моделей. Снижение зависимости возможно за счёт использования открытых стандартов, контейнеризации приложений и абстрагирования от платформенно-специфических сервисов, однако полное её устранение на практике достигается редко.",[15,287,288],{},"Третий риск — сложность прогнозирования полной стоимости владения. Облачные тарифы формируются из множества компонентов: стоимость вычислений, хранения, сетевого трафика, операций ввода-вывода, использования дополнительных сервисов. Прозрачное прогнозирование итоговой стоимости требует понимания модели тарификации каждого используемого компонента. Неверный прогноз может привести к тому, что реальные затраты значительно превысят бюджет, а обратная миграция окажется сложной и дорогостоящей.",[15,290,291],{},"Перечисленные риски не обесценивают преимуществ облачной модели, но требуют осознанного подхода. Решение о переходе в облако должно основываться на анализе конкретных условий, а не на предположении о безусловной экономической выгоде.",[25,293,295],{"id":294},"итоги-темы","Итоги темы",[15,297,298],{},"Облачные вычисления представляют собой модель предоставления вычислительных ресурсов по запросу, основанную на принципах самообслуживания, эластичности, широкой сетевой доступности, объединения ресурсов и измеряемости потребления. Эта модель принципиально отличается от традиционного хостинга и локальной серверной инфраструктуры прежде всего программной определяемостью ресурсов и динамическим характером их выделения.",[15,300,301],{},"Модели предоставления сервисов — IaaS, PaaS и SaaS — образуют спектр от максимального контроля при высокой эксплуатационной нагрузке до минимального контроля при минимальной нагрузке. Выбор модели определяется конкретными требованиями к гибкости, управляемости и степени делегирования ответственности поставщику. Границы между моделями подвижны, а современные облачные платформы предлагают сервисы, сочетающие признаки нескольких уровней.",[15,303,304],{},"Модели развертывания — публичное, частное и гибридное облако — различаются по критериям принадлежности инфраструктуры, уровня контроля и нормативного соответствия. Каждая из них имеет свою область применимости, и выбор должен основываться на анализе требований к безопасности, стоимости, масштабируемости и зрелости инженерных практик организации.",[15,306,307],{},"Экономические эффекты облака связаны с трансформацией капитальных затрат в операционные, с возможностью эластичного выделения ресурсов и со снижением избыточного резервирования. Однако эти преимущества сопровождаются рисками неконтролируемого роста потребления, зависимости от поставщика и сложности прогнозирования полной стоимости владения. Осознанный переход к облачной модели требует не только технической компетенции, но и понимания экономических и организационных последствий принимаемых решений.",[15,309,310],{},"Рассмотренные в данной теме основы создают концептуальную базу для дальнейшего изучения технологий, составляющих ядро облачной инфраструктуры. Следующая тема посвящена виртуализации — фундаментальному механизму, обеспечивающему абстрагирование физических ресурсов и формирование управляемых вычислительных сред, на которых строится большинство облачных платформ.",{"title":312,"searchDepth":313,"depth":313,"links":314},"",2,[315,321,327,333,338],{"id":27,"depth":313,"text":28,"children":316},[317,319,320],{"id":32,"depth":318,"text":33},3,{"id":45,"depth":318,"text":46},{"id":82,"depth":318,"text":83},{"id":98,"depth":313,"text":99,"children":322},[323,324,325,326],{"id":105,"depth":318,"text":106},{"id":118,"depth":318,"text":119},{"id":131,"depth":318,"text":132},{"id":144,"depth":318,"text":145},{"id":165,"depth":313,"text":166,"children":328},[329,330,331,332],{"id":172,"depth":318,"text":173},{"id":185,"depth":318,"text":186},{"id":198,"depth":318,"text":199},{"id":211,"depth":318,"text":212},{"id":226,"depth":313,"text":227,"children":334},[335,336,337],{"id":233,"depth":318,"text":234},{"id":254,"depth":318,"text":255},{"id":275,"depth":318,"text":276},{"id":294,"depth":313,"text":295},"aidt-bac-cloud_tech",null,"md",false,{},true,"\u002Fcourses\u002Faidt-bac-cloud_tech\u002Ftopic-01-content","content",{"title":6,"description":17},"courses\u002Faidt-bac-cloud_tech\u002Ftopic-01-content",1,"topic-01","_-ng4y7ZULsC5fiHJ07rpBeT2Ty1kfMY5U87W42ocg4",{"id":353,"title":354,"body":355,"course_slug":339,"description":312,"env_label":340,"env_url":340,"extension":341,"group":340,"is_course_project":342,"is_index":342,"level":340,"meta":671,"navigation":344,"path":672,"section":673,"seo":674,"stem":675,"topic_number":349,"topic_slug":350,"__hash__":676},"courses\u002Fcourses\u002Faidt-bac-cloud_tech\u002Ftopic-01-lr.md","Лабораторная работа 1. Основы облачных технологий",{"type":8,"value":356,"toc":660},[357,360,364,367,371,374,378,381,385,388,395,401,407,413,418,434,440,444,447,451,456,559,570,575,579,582,586,603,608,612,615,630,633,637],[11,358,354],{"id":359},"лабораторная-работа-1-основы-облачных-технологий",[25,361,363],{"id":362},"цель-работы","Цель работы",[15,365,366],{},"Сформировать практические навыки анализа прикладных сценариев с точки зрения выбора облачной модели. Научиться сопоставлять модели предоставления сервисов (IaaS, PaaS, SaaS) и модели развертывания (публичное, частное, гибридное облако) по набору инженерных и экономических критериев. Подготовить обоснованное проектное решение и представить его в виде схемы целевой инфраструктуры.",[25,368,370],{"id":369},"предварительные-сведения","Предварительные сведения",[15,372,373],{},"Лабораторная работа носит аналитический характер и не требует развертывания программного обеспечения. Основным результатом является документ, содержащий структурированный анализ и обоснование архитектурных решений. Для выполнения работы необходимо владеть материалом первой темы курса.",[25,375,377],{"id":376},"задание","Задание",[15,379,380],{},"Работа состоит из трёх последовательных частей. Каждая часть завершается оформлением результата, который включается в итоговый отчёт.",[30,382,384],{"id":383},"часть-1-анализ-прикладного-сценария-и-выбор-модели-развертывания","Часть 1. Анализ прикладного сценария и выбор модели развертывания",[15,386,387],{},"Выберите один из предложенных сценариев (или согласуйте собственный с преподавателем).",[15,389,390,394],{},[391,392,393],"strong",{},"Сценарий A."," Стартап из пяти разработчиков запускает веб-приложение для бронирования спортивных площадок. Ожидаемая аудитория — до 10 000 пользователей в первый год. Бюджет на инфраструктуру ограничен, команда не располагает системным администратором. Нагрузка на приложение имеет выраженную суточную и сезонную неравномерность.",[15,396,397,400],{},[391,398,399],{},"Сценарий B."," Медицинская организация планирует развернуть систему хранения и обработки результатов лабораторных исследований. Данные содержат персональную медицинскую информацию и подпадают под требования законодательства о защите персональных данных. Объём данных растёт линейно и предсказуемо. Организация располагает собственной серверной инфраструктурой и штатом системных администраторов.",[15,402,403,406],{},[391,404,405],{},"Сценарий C."," Образовательное учреждение организует учебную среду для курса по разработке программного обеспечения. Каждому студенту необходима изолированная виртуальная машина с предустановленным набором инструментов. Среда используется в течение семестра, после чего ресурсы освобождаются. Нагрузка концентрируется в часы занятий и в периоды сдачи заданий.",[15,408,409,412],{},[391,410,411],{},"Сценарий D."," Производственное предприятие с несколькими филиалами внедряет систему мониторинга оборудования. Датчики передают телеметрию в центральное хранилище. Часть данных является коммерческой тайной, но аналитические отчёты должны быть доступны руководителям филиалов через веб-интерфейс. Нагрузка на систему сбора данных стабильна, но нагрузка на аналитический модуль возрастает в периоды подготовки отчётности.",[15,414,415],{},[391,416,417],{},"Порядок выполнения:",[419,420,421,425,428,431],"ol",{},[422,423,424],"li",{},"Определите ключевые характеристики сценария: характер нагрузки, требования к безопасности и нормативному соответствию, бюджетные ограничения, наличие технического персонала, предсказуемость роста.",[422,426,427],{},"Выберите модель развертывания (публичное, частное или гибридное облако) и обоснуйте выбор. Укажите, какие факторы были решающими и какие альтернативы вы рассматривали.",[422,429,430],{},"Если выбрана гибридная модель, опишите, какие компоненты размещаются в публичном сегменте, какие — в частном, и каким образом обеспечивается связность между ними.",[422,432,433],{},"Укажите ограничения и риски выбранной модели применительно к данному сценарию.",[15,435,436,439],{},[391,437,438],{},"Результат:"," текстовое обоснование выбора модели развертывания (1–2 страницы).",[30,441,443],{"id":442},"часть-2-сопоставление-моделей-предоставления-сервисов","Часть 2. Сопоставление моделей предоставления сервисов",[15,445,446],{},"Для того же прикладного сценария выполните сравнительный анализ моделей IaaS, PaaS и SaaS.",[15,448,449],{},[391,450,417],{},[419,452,453],{},[422,454,455],{},"Заполните сравнительную таблицу по следующим критериям:",[457,458,459,478],"table",{},[460,461,462],"thead",{},[463,464,465,469,472,475],"tr",{},[466,467,468],"th",{},"Критерий",[466,470,471],{},"IaaS",[466,473,474],{},"PaaS",[466,476,477],{},"SaaS",[479,480,481,493,504,515,526,537,548],"tbody",{},[463,482,483,487,489,491],{},[484,485,486],"td",{},"Зона ответственности потребителя",[484,488],{},[484,490],{},[484,492],{},[463,494,495,498,500,502],{},[484,496,497],{},"Гибкость выбора технологического стека",[484,499],{},[484,501],{},[484,503],{},[463,505,506,509,511,513],{},[484,507,508],{},"Требования к квалификации персонала",[484,510],{},[484,512],{},[484,514],{},[463,516,517,520,522,524],{},[484,518,519],{},"Скорость развертывания",[484,521],{},[484,523],{},[484,525],{},[463,527,528,531,533,535],{},[484,529,530],{},"Возможность масштабирования",[484,532],{},[484,534],{},[484,536],{},[463,538,539,542,544,546],{},[484,540,541],{},"Степень зависимости от поставщика",[484,543],{},[484,545],{},[484,547],{},[463,549,550,553,555,557],{},[484,551,552],{},"Применимость к данному сценарию",[484,554],{},[484,556],{},[484,558],{},[419,560,561,564,567],{"start":313},[422,562,563],{},"Для каждого критерия дайте краткую оценку применительно к выбранному сценарию, а не абстрактную характеристику модели.",[422,565,566],{},"На основании таблицы выберите модель (или сочетание моделей), наиболее подходящую для рассматриваемого сценария. Обоснуйте выбор.",[422,568,569],{},"Укажите, какие компоненты системы могут использовать разные модели. Например, база данных может быть реализована как управляемый сервис (PaaS), а прикладной сервер — как виртуальная машина (IaaS).",[15,571,572,574],{},[391,573,438],{}," заполненная таблица и текстовое обоснование выбора модели предоставления сервисов (1–2 страницы).",[30,576,578],{"id":577},"часть-3-схема-целевой-инфраструктуры","Часть 3. Схема целевой инфраструктуры",[15,580,581],{},"На основании решений, принятых в частях 1 и 2, подготовьте схему целевой инфраструктуры.",[15,583,584],{},[391,585,417],{},[419,587,588,591,594,597,600],{},[422,589,590],{},"Изобразите основные компоненты системы: прикладные сервисы, хранилища данных, сетевые границы, точки доступа пользователей.",[422,592,593],{},"Обозначьте, какая модель предоставления (IaaS, PaaS, SaaS) используется для каждого компонента.",[422,595,596],{},"Обозначьте границу ответственности потребителя и поставщика.",[422,598,599],{},"Если используется гибридная модель, покажите разделение на публичный и частный сегменты и каналы связи между ними.",[422,601,602],{},"Подготовьте краткое пояснение к схеме (0,5–1 страница), в котором опишите логику размещения компонентов и ожидаемые эксплуатационные свойства: масштабируемость, отказоустойчивость, безопасность.",[15,604,605,607],{},[391,606,438],{}," схема целевой инфраструктуры и пояснительная записка.",[25,609,611],{"id":610},"требования-к-оформлению-отчёта","Требования к оформлению отчёта",[15,613,614],{},"Отчёт должен содержать:",[616,617,618,621,624,627],"ul",{},[422,619,620],{},"титульный лист с указанием номера лабораторной работы, темы, имени студента и номера группы;",[422,622,623],{},"указание выбранного сценария;",[422,625,626],{},"результаты каждой из трёх частей задания;",[422,628,629],{},"список источников, если при выполнении использовались внешние материалы.",[15,631,632],{},"Схему целевой инфраструктуры допускается выполнять в любом графическом редакторе или от руки с последующим сканированием. Обязательно наличие подписей к элементам схемы.",[25,634,636],{"id":635},"контрольные-вопросы","Контрольные вопросы",[419,638,639,642,645,648,651,654,657],{},[422,640,641],{},"Перечислите пять существенных признаков облачной среды согласно определению NIST. Какой из признаков, по вашему мнению, наиболее сложно реализовать на практике и почему?",[422,643,644],{},"В чём состоит принципиальное отличие облачной модели вычислений от традиционного хостинга?",[422,646,647],{},"Объясните, как проходит граница ответственности между потребителем и поставщиком в моделях IaaS, PaaS и SaaS.",[422,649,650],{},"Приведите пример ситуации, в которой частное облако является более обоснованным выбором, чем публичное. Какие факторы определяют этот выбор?",[422,652,653],{},"Что такое зависимость от поставщика (vendor lock-in)? Какие меры позволяют снизить эту зависимость?",[422,655,656],{},"Объясните различие между капитальными (CapEx) и операционными (OpEx) затратами. В каких случаях переход от CapEx к OpEx может не привести к снижению расходов?",[422,658,659],{},"Почему эластичность облачной среды является не только инфраструктурным свойством, но и архитектурным требованием к приложению?",{"title":312,"searchDepth":313,"depth":313,"links":661},[662,663,664,669,670],{"id":362,"depth":313,"text":363},{"id":369,"depth":313,"text":370},{"id":376,"depth":313,"text":377,"children":665},[666,667,668],{"id":383,"depth":318,"text":384},{"id":442,"depth":318,"text":443},{"id":577,"depth":318,"text":578},{"id":610,"depth":313,"text":611},{"id":635,"depth":313,"text":636},{},"\u002Fcourses\u002Faidt-bac-cloud_tech\u002Ftopic-01-lr","lr",{"title":354,"description":312},"courses\u002Faidt-bac-cloud_tech\u002Ftopic-01-lr","PeK0ArqlpIgRBGjo1ar0IS9XAQXWJFesm0kFeAU5qkg",{"id":678,"title":679,"body":680,"course_slug":339,"description":312,"env_label":340,"env_url":340,"extension":341,"group":711,"is_course_project":342,"is_index":344,"level":712,"meta":713,"navigation":344,"path":717,"section":340,"seo":718,"stem":719,"topic_number":340,"topic_slug":340,"__hash__":720},"courses\u002Fcourses\u002Faidt-bac-cloud_tech\u002Findex.md","Облачные технологии",{"type":8,"value":681,"toc":709},[682,685],[11,683,679],{"id":684},"облачные-технологии",[616,686,687,695,702],{},[422,688,689,690],{},"Требования к материалам: ",[691,692,694],"a",{"href":693},".\u002Fshared\u002FSTYLEGUIDE","shared\u002FSTYLEGUIDE.md",[422,696,697,698],{},"Содержание курса: ",[691,699,701],{"href":700},".\u002Ftopics","topics.md",[422,703,704,705],{},"Инструкция по сдаче работ: ",[691,706,708],{"href":707},".\u002Fshared\u002Fsubmission","shared\u002Fsubmission.md",{"title":312,"searchDepth":313,"depth":313,"links":710},[],"bachelor","бакалавриат",{"topics_count":714,"has_lr":344,"has_pz":342,"has_course_project":344,"final_assessment":715,"tech_focus":716},12,"зачет","Облачные технологии, контейнеризация, Docker","\u002Fcourses\u002Faidt-bac-cloud_tech",{"title":679,"description":312},"courses\u002Faidt-bac-cloud_tech\u002Findex","uo9ftIk0ye9G2gRrb5M7uFNZQgYvuCJ8j7yJSmoQuGo",1779455410874]