Портал №1 по управлению цифровыми
и информационными технологиями

Изменение или запрос на обслуживание

Опубликовано 16 апреля
Рубрики: ITIL, ITSM, Обо всём на свете, Обсуждения на учебных курсах, Процессы, Управление изменениями, Эксплуатация ИТ
Комментарии

На курсе «Основы управления ИТ-услугами» нередко возникает дискуссия по поводу того, как провести границу между практиками управления изменениями и управления запросами на обслуживания.

Вызвана она тем, что часто в рамках выполнения запроса на обслуживание реализуется изменение. Например, установка программного обеспечение, изменение прав доступа, перемещение или изменение конфигурации оборудования. Поэтому некоторые усваивают это в упрощённом виде: «Запрос на обслуживание – это стандартное изменение». И в этом случае теряются ориентиры. Как соотносятся эти практики, если в рамках одной выполняется работа с объектом, который является основным объектом управления в другой?

Справедливости ради стоит заметить, что нечто похожее на «запрос на обслуживание [ЗНО] – это стандартный запрос на изменение [ЗНИ]) мы можем увидеть и в библиотеке ITIL. Например, в книге «Основы» стандартное изменение описывает следующим образом.

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

И далее:

They are often initiated as service requests…

Т.е. они [стандартные изменения] часто инициируются как запросы на обслуживание.
Так, что, запросы на обслуживание – это стандартные изменения? Нет!

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

Есть способность организации (aka «практика») управлять изменениями (поддерживать изменения). Как и любая практика, эта практика у организации появляется и развивается за счёт появления и развития соответствующего набора процессов (возможно состоящего из одного процесса), технологий, соответствующих специалистов и прочих ресурсов организации, сконфигурированных необходимым образом.
Конкретно практика «изменения» предназначена для того, чтобы

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

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

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

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

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

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

Так что, нет, ЗНО – это не стандартные ЗНИ 😉

PS

Кстати, фраза про стандартные изменения, цитата из которой приведена выше в оригинале, целиком выглядит так:

They are often initiated as service requests, but may also be operational changes.

А в практическом руководстве «Change enablement» приводится ещё больше примеров сценариев, в которых могут реализоваться стандартные изменения:

  • выполнение запроса обслуживание
  • типовые решения инцидентов
  • стандартные меры реагирования на чрезвычайные ситуации (в соответствии с ПАВ [DRP])
  • обслуживание инфраструктуры
  • плановое тестирование мер на случай непредвиденных обстоятельств
  • высокоавтоматизированные изменения, проходящие через конвейер CI/CD
  • рутинные обновления программного обеспечения.
ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

Комментариев: 10

  • Артём

    Не очень складывается картинка.

    Стандартные изменения – изменения…, предварительно авторизованные, … полностью документированные; могут быть реализованы без дополнительной авторизации.

    А в абзаце, который вроде бы должен являться ключом к решению, внезапно появляются модели с предопределённым маршрутом согласования и деятельностью… “которая может быть довольно сложной и длительной, с большим количеством участников” – это точно всё ещё про стандартные изменения?

    • Анна Васильева

      Артём, возможно, картинка сложится лучше, если разобраться, о каких согласованиях идет речь.
      Говоря, что мы “стандартизовали” изменение – мы говорим, что мы сделали стандартным весь порядок шагов по его выполнению: кто, что, когда и как должен сделать и в какой последовательности. Т.е. мы предварительно составили план, что, например, проводя изменение в системе рассылки сообщений, мы сначала отключаем мониторинг сервера 1, потом 2, потом отключаем сам сервер 1, а второй не отключаем, а не наоборот. Также мы предварительно определили (и нам это авторизовали), что мы проводим именно такие тесты, а не другие, а какие-то не проводим, и прочие шаги реализации изменения. Вот эта последовательность шагов и была “предварительно авторизована, документирована и ее не надо дополнительно авторизовывать”.
      При этом одним из шагов может быть, например, получение согласования со стороны ИБ (и прописан порядок, как и у кого такое согласование получать) или со стороны финансов. Или что нужно получить от заказчика письменное подтверждение даты проведения изменения. Об этих согласованиях идет речь во второй части.

      • Игорь Гутник

        Всё так.
        Но я бы на всякий случай добавил. Основная задача стандартизации — снижение рисков до приемлемого уровня. При это соображения рациональности никто не отменял.
        Это означает, что на практике у нас могут быть стандартные изменения, модель которых не включает в себя детальной, пошаговой инструкции
        Представим себе, что у нас есть специалисты (или групп[а/ы] специалистов), которые, будучи действительно специалистами, в своей предметной области, могут с достаточным для нас уровнем предсказуемости (по рискам, срокам) решать задачи определённого типа. Ну, вот такой вот “он придёт и молча поправит всё…” (c)
        Будем ли тратить время на написание (и поддержание в актуальном состоянии) пошаговой инструкции для этого сценария? – Возможно, что нет.
        Модель в данном случае заключается в том, что “немедля звони человеку из Кемерова” (c)

    • Игорь Гутник

      Артём, уточните, пожалуйста, в какой части видите противоречие?
      Два абзаца в вашем комментарии, если я правильно понял, противопоставляются. Но я не вижу, почему.

      На всякий случай, вот как выглядит моя картина мира, если коротко.
      1. Модель — это, по сути, инструмент стандартизации.
      2. Частью того, что нам может понадобится стандартизировать, могут быть процедуры согласования.
      3. Стандартизировать (т.е. определиться модель для) можно как простые изменения, так и сложные изменения (т.е. изменения, включающие множество различных разбор, выполняемых различными участниками, и ттребующие различных согласований).
      Более того, возможно, приоритет в очереди на стандартизацию у сложных изменений будет весьма высоким. Ведь он (приоритет) определяется не только простотой, но и эффектом (CDDD aka WSJF и вот это вот всё). Например, модели для экстренных изменений (emergency changes).

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

      • Артём

        Добрый день.

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

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

        Процессы и модели, которые описаны на уровне “звони такому-то”, мгновенно рушатся, как только уходит такой эксперт. Разрушительные результаты недокументированных процессов, завязанных на конкретного эксперта, которому некогда документировать, думаю все видели в своей практике. Bus factor и всё такое.

        • Игорь Гутник

          Артём, у нас, как мне кажется есть два расхождения. Одно терминологическое, другое по сути.
          По первому. Я, возможно, слишком неосторожно использовал слово «стандартизация», имея в виду деятельность, а не результат. То есть стандартизация в данном случае – это работа по снижению вариативности, рисков. Результатом такой деятельности может появление стандартного изменения, а может не быть. Т.е. мы что-то про данный тип изменения для себя выяснили, о чём-то договорились, возможно, разработали модель. Но! Будем ли мы считать его стандартным. Зависит от того, как мы используем это понятие. Вполне возможно, если, например, мы по всем изменениям, которые признаны у нас стандартными, мы не создаём ЗНО (RFC). Так как такие изменения отрабатываются в рамках других процессов/практик (например, управление запросами на обслуживание [другие примеры приведены в самом конце заметки]). В охвате управления изменениями остаётся лишь ответственность за актуальность утверждённого подхода к реализации данного типа изменений.

          Итого «модель – инструмент стандартизации, где под стандартизацией понимается упорядочение», а не делание изменений стандартными. Моя вина. Наверное, не следовало так использовать слово «стандартизация» (прошу прощения, привычка).

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

          1. Они совпадают, когда в организации понятие «модель» идентично понятию «стандарт» (или как у них называется документ, наличие которого означает, что изменение стандартное»).
            Артём, судя по фразе «Само по себе описание модели изменения не делает изменение стандартным.», Вы не здесь.
          2. Когда все «стандарты» появляются путём проработки, в ходе которой сначала появляется какое-то более верхнеуровневое предоставление о способе реализации изменений данного типа, часть этих представлений мы возможно сочтём небесполезным задокументировать. Появляется «модель» «модель». В таком случае множество «стандартных» будет подмножеством «отмоделированных» («модельных»? 😊).
            Легко представить, что в компаниях, которые очень хотят навести чёткий порядок во всём, и за ценой не постоят ради этого, сам процесс по разработке «моделей» и «стандартов» может быть очень жёстко и детально стандартизирован. 😊 Тогда, раз жизненный цикл изменения предопределён (в какой-то момент может появиться модель, потом (и только потом!) может появиться стандарт), организация будет находиться в этой картине мира.
            Артём, судя по фразе «Само по себе описание модели изменения не делает изменение стандартным.», Вы не здесь.
          3. Более жизненный, на мой взгляд, сценарий, когда подмножества «стандартные» и «отмоделированные» пересекаются. Но не совпадают. То есть, есть стандартные изменения, для которых нет моделей. Есть «отмоделированные» изменения, для которых нет «стандартов». Но в организации в том числе реализуются изменения, которые сначала обрабатываются по соответствующей модели, а в какой-то момент мы понимаем, что для изменения, с которым мы имеем дело, у нас есть стандарт. Более того, какое-то большое и сложно изменение, обрабатываемое по модели может «распадаться» на части, какая-то доля которых может быть обработана по «стандартам».
          4. Возможно (допускаю с трудом) существуют организации, в которых этим подмножества НЕ пересекаются. То есть по какой-то части изменений есть модели разной степени выскоуровневости, описывающие общие идеи, подходы. И разработка таких моделей – это один поток работ. Совершенно другой поток работ, не связанный с «моделированием» – разработка стандартов. Тогда картинка получается бинарной. Каждое изменение из этих двух подмножеств («стандартные» и «отмоделированные») в любой момент времени принадлежит только к одному из них. Даже если, например, для какого-то типа изменений существовала модель, после разработки разработан стандарта для этого типа изменений. Мы обрабатываем их как стандартные. Мне такая организация работы кажется странной и далёкой от оптимальной. Но я не вижу здесь внутреннего противоречия. Поэтому, так как в жизни чего только ни бывает, не удивлюсь, если где-то работает так.

          Замечу, кстати, что, насколько я помню, авторы ITIL4 не проводят чёткую связь/границу между сущностями модель и стандартное изменение. Поэтому в данном комментарии я использовал понятие «стандартное» и «отмоделированное». Хотя чаще (в т.ч. прочих текстах на этой же странице) пользуюсь одним понятием «модель», трактуя его шире.

          Стало ли так лучше? Или мы ещё больше запутались в терминологии?

          Расхождение же по сути, как я вижу, в том, что мы по-разному отвечаем на вопрос: «Может ли быть большое и/или сложное изменение стандартным?» Разумеется, здесь можно было бы предположить, что имеется опять расхождение в понимании того, как вы определяете «стандартное изменение», и, самое главное, как используется на практике наличие такой категории. Но по сумме Ваших комментариев и того, как Вы интерпретировали некоторые мысли, у меня сложилось впечатление (возможно, ошибочное), что картина для Вас чёрно-белая. Что с моделями, что со стандартами. Например, если мы имеем дало со стандартом, то это, грубо говоря, пошаговая инструкция, очень детальное описание.

          Я не против такой картины. Она выглядит более упорядоченной, более управляемой, с меньшими рисками. И тем привелкательной. Но и более дорогой. Как только мы задумываемся об эффективности (в смысле рациональности, efficiency), всё становится несколько сложнее, как мне кажется. Риск-менеджмент ведь ровно про это – оценить вероятность и размер последствий и предпринять сообразные риску усилия для приведения его к приемлемой конфигурации. Именно поэтому в умных книжках в контексте стандартизации (понимаемой в этом предложении как длительность по упорядочению, не обязательно сводящейся только к разработке «стандартов») говорится о снижении рисков, а не устранении.

  • Владимир

    Тема отделения изменений от всех остальных процессов выглядит несколько притянутой и неестественной: “В рамках практики «изменения» происходит управление изменениями” противопоставляется “В рамках прочих практик и процессов (включая практику управления запросами на обслуживание) по-хорошему тоже нужно выстроить регулярную деятельность”. Аналогично выглядит разделение менеджеров процессов, которые по тексту статьи действуют совершенно разобщенно.
    Если такая проблема действительно есть и весьма распространена, может быть есть смысл работать с этой разобщенностью менеджеров, управляющих ИТ-процессами, а не перетягивать “стандартные изменения” в область управления изменениями под предлогом “невозможно реализовать в полной мере, если в охват не будут попадать все изменения”?

    • Игорь Гутник

      Владимир, давайте прямо по пунктам, т.к. я не уверен, что всё понял (ну, или точно не имел в виду некоторые из проведённых тезисов).
      1. Что имеете в виду, говоря про притянутость темы “отделения изменений от всех остальных процессов”?
      Это устоявшаяся практика. Во многих сводах знаний (ITIL, ISO/ГОСТ, COBIT…) есть отдельная штука (процесс/практика/область деятельности) про управление изменениями. Если мы принимаем такую модель системы управления, то нам нужно понимать границы каждой сущности, описываемой в модели. Т.е. вопрос “отделения” не праздный.

      2. Если из фрагмента ““В рамках практики «изменения» происходит управление изменениями” противопоставляется “В рамках прочих практик и процессов (включая практику управления запросами на обслуживание)”” убрать слово “противопоставляется”, то с какой частью Вы не согласны?
      2.а. Нужно ли заниматься стандартизацией в рамках управления изменениями?
      2.б. Нужно ли заниматься стандартизацией деятельности (часть которой является по сути изменениями) в рамках прочих областей управления?
      <Мои ответы на оба вопроса положительные. А Ваши?>

      3. Я, вроде бы, не писал про менеджеров процессов. Просто, чтобы не загромождать и так непростую картину. Задача же — разобраться, а не запутать. Покажите, пожалуйста, то место в тексте, которое, на Ваш взгляд, требует для дальнейшего обсуждения, введения дополнительной сущности (pm).

      4. Разобщённость менеджеров (в т.ч. менеджеров ИТ-процессов) — проблема, с которой нужно работать. Полностью с Вами согласен.
      Но, чтобы “давайте преодолеем разобщённость” не осталось просто лозунгом, нужно разобраться, в том, как всё устроено (или должно быть устроено). Ровно это и обсуждаем — как могут быть устроены границы (для простоты, оставляя, насколько это возможно, за скобками интерфейсы, роли и пр. важные вещи).

      5. Конструкцию “…перетягивать “стандартные изменения” в область управления изменениями под предлогом “невозможно реализовать в полной мере, если в охват не будут попадать все изменения”” я, к сожалению, совсем не понял.
      Вы не согласны с назначением процесса/практики? Т.е. мы не ожидаем от этого элемента нашей системы управления того, что доля успешных изменений будет расти? Вряд ли, ведь?
      Или предлагаете, ограничить охват? Т.е. каждый процесс/практика будет заниматься своей частью изменений, а CHG превращается из нашей способности обеспечить повышение доли успешных изменений (за счёт управленческих воздействий) в управление реализацией изменений. В реальной жизни это, грубо говоря, выглядит так. Когда нам нужно сильно изменить что-то, например, в наших ключевых бизнес-системах — добро пожаловать в “управление изменениями”. А всё остальное — мимо (это либо операционные изменения, либо наоборот изменения “стратегического уровня”).
      Так можно рассуждать. Но это не единственная возможная картина мира. И точно не всегда самая эффективная. Как раз потому, что возникает дублирование и зоопарк (разные решения одинаковых задач).
      Можно ли решить эту проблему только снижением разобщённости? — В какой-то степени.
      Если этого инструмента будет недостаточно (или по каким-либо причинам он нам недоступен), то нужно разбираться с устройством системы управления.
      Или в этом фрагменте была заложена другая идея?

  • Синан Алиев

    Добрый День.
    “Так что, нет, ЗНО – это не стандартные ЗНИ 😉” – согласен.
    Но почти все ЗНИ – это часть ЗНО.

    Ну начнем просто с того что “любое добавление, модификация или удаление которое влияет на услугу” это изменение. То есть поменял катридж – это изменение? Сменил пароль – это изменение? Что теперь делать, править этим где? Request или в Change?

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

    Значит есть риск.

    Такая ситуация требует изучения, тестирования, контроля, утверждения. Отправляем в Change Enablement. Привлекаются эксперты, определяется состав change authority. После первой успешной интеграции оказалось что задача проста, риск стал низким (тестами определили вероятность, дублированием и другими способами уменьшили возможное влияние) и теперь можно его проводить без обсуждений. Короче всем все стало ясно и не больно. Неизвестности и влияния существенно меньше (читай риск)!

    Не нужно вновь собирать change authority. Не нужно делать Impact assessment, не нужно разрабатывать специфические планы rollback и тп.

    Такое изменение стало для нас стандартным. Пре-авторизованным. Его исполнение можно отдать в Request fullfillment.

    Смотрите источники:
    COBIT2019, DSS02.02 Record, classify and prioritize requests and incidents.
    Activities:
    1. Verify entitlement for service requests using, where possible, a predefined process flow and standard changes.
    2. Obtain financial and functional approval or sign-off, if required, or predefined approvals for agreed standard changes.

    ITIL4, Service request management practice guide, 2.1
    “Fulfilling service requests may include changes to services or their components; these are usually standard changes”

    ITIL4, Service request management practice guide, 2.2
    A service request is a normal part of service delivery, which is ‘business as usual’.

    ITIL4, Change Enablement practice guide, 2.2.1
    “Examples of standard changes include
    – fiullfillment of a service request”

    ITIL4, Change Enablement practice guide, 2.2.1
    “Although standard changes are usually associated with business-as-usual situations, …”

    ITILv3, SO, 3.1.3.4 Request fulfilment

    “A service request is associated with a request model that defines any prerequisites, authorizations needed and standard work steps and activities to fulfil it. As part of that request model, standard changes and other types of requests for change (RFCs) may be needed to complete fulfilment actions.” – Здесь обратите внимание что request model это часть запроса, а в нам находится стандартное изменение. То есть мы не вышли из практики Request Management и не отдали управление в Change Enablement.

    ITILv3, ST, 4.2.4.7 Standard changes (pre-authorized)
    “Some standard changes will be triggered by the request fulfilment process and be directly recorded and passed for action by the service desk.”

    Остается последний маленький нюанс.
    Управляем в Request Fulfillment, а нужен ли какой то доп контроль этих стандартных изменений в Change Enablement

    “Service requests that impact CIs should usually be satisfied by implementing a standard change (see ITIL Service Transition for further details
    on standard changes). This ensures that change management does not lose track of changes that may be introduced to CIs through request fulfilment activities.”

    Говорят посмотрите в Service Transition, смотрим:
    ITILv3, ST, 4.2.4.7 Standard changes (pre-authorized)
    Some standard changes to configuration items may be tracked on the asset or configuration item lifecycle, particularly where there is a
    comprehensive CMS that provides reports of changes, their current status, the related
    configuration items and the status of the related CI versions. In these cases the change management and service asset and configuration management reporting is integrated, and change management can have ‘oversight’ of all changes to service CIs
    and release CIs.

    • Игорь Гутник

      Синан, спасибо большое за обширную документальная справку!
      Думаю, всем будет небесполезно и небезынтересно.

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

      “Так что, нет, ЗНО – это не стандартные ЗНИ 😉” – согласен.

      Супер!

      Но почти все ЗНИ – это часть ЗНО.

      Не совпадаем.
      Если под ЗНИ (aka RFC) и ЗНО (aka SR) понимать ровно то, что стоит за этими названиями, то фраза «ЗНИ – это часть ЗНО» содержит неточность.
      Если в этой фразе заменить «ЗНИ» на «изменение», то становится лучше. Мы действительно в рамках выполнения части запросов на обслуживание производим изменения. При этом во многих случаях при обработке ЗНО не требуется порождение нового объекта управления (ЗНИ). Ваш прекрасный пример «стандартизации» как раз это показывает. Во второй части описанной Вами истории понадобится ЗНО, но не понадобится ЗНИ.

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

      Второй абзац Вашего комментария не понял. Этот вопрос к определению термина «изменение»? Тогда в чём он? Пример с картриджем каким-то образом бросает данному определению вызов? Не понимаю, какой.
      Судя по тому, что написано в примере с банковской интеграцией, наши картины мира похожи. Но тогда непонятно, зачем подвешен вопрос во втором абзаце. Замените банковскую интеграцию на картридж. Все рассуждения те же самые. И, как Вы правильно пишете, в качестве вывода из примера, «такое изменение стало для нас стандартным». Что смущает в картридже?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.