Получить отчет
Оставьте ваши контакты для просмотра отчета
Имя *
E-mail *






Новости







Что делать, если хочется повышения?

Итак, этот день настал! Вы чувствуете, что ваши усилия были не напрасны, вы стали делать задачи лучше, быстрее, ответственности берете на себя больше. Кажется, самое время подумать о повышении: зарплаты и/или позиции.

Как это сделать, как выстроить разговор, к чему готовиться — об этом короткая заметка.

  1. Трезво оцените то, насколько изменились ваши задачи с того момента, как вы начали работать на текущей позиции. Или с момента последнего промоута. Действительно ли вы стали приносить больше пользы продукту/проекту/команде? Если да, то можно ли это посчитать?
  2. Посчитайте, напишите, разложите по полочкам то, что вы стали делать больше или лучше из прошлого пункта. Приведите примеры, постарайтесь оценить их с точки зрения пользы для проекта/бизнеса/команды.
  3. Если в компании есть грейды/уровни, то изучите их описание и поймите, с теми навыками и задачами, что вы справляетесь, вы уже соответствуете следующей ступени? Может есть чек-листы? Пройдите по ним и постарайтесь оценить себя.
  4. Со всей обобщенной информацией идите к лиду. Инициируйте встречу/созвон и заранее напишите и отправьте вопросы, которые вы хотите с лидом обсудить.
  5. Постарайтесь подойти к разговору в нейтральной позиции и с желанием понять и разобраться. Не пытайтесь "качать права" или вести себя из позиции обиженного сотрудника. В ваших же интересах как следует разобраться в том, как профессионально и карьерно развиваться. Лучше действовать с холодной головой и не стараться решить все за один разговор.
  6. Изложите лиду свои рассуждения. То, о чем вы размышляли выше. Максимально структурировано. Подкрепите свои доводы примерами задач или реализованными проектами.
  7. Задайте вопрос "могу ли я претендовать на следующий грейд?"
  8. Варианта ответа может быть два:

— "Да!" Ок, осталось проговорить сроки, переход на новую позицию, то, как изменятся задачи и ответственность, что добавится, а какие задачи уйдут.

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

  1. Вы великолепны!

 

Рушана, HR Lead E42







Как говорить о причине ухода с прошлого места работы на собеседовании?

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


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

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

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

  3. Это называется рефлексия.

  4. Если на собеседовании зададут вопрос о причинах ухода, то, в таком случае, лучше отвечать честно. Честно в нашей ситуации — это "моих навыков оказалось недостаточно для решения задач, самостоятельный поиск ответов не давал результатов; я работал в команде один и обратиться к более опытному коллеге не было возможности". И закончить рассказ своими выводами: "поэтому сейчас для меня важно работать над проектом, где есть такие же как я, но более опытные". Так для рекрутера/нанимающего лида будет очевидно, что вы не снимаете с себя ответственность, и что способны делать выводы по итогам случившегося.

  5. Вы великолепны!

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

Ошибаться - это нормально!

 

Рушана, HR Lead E42







4 антипаттерна DevOps, которые приведут к катастрофе

Как и в любой другой практике, в DevOps есть свои разрушительные антипаттерны.

И некоторые из них, такие как знаменитый антипаттерн «Герой», описанный ниже, поначалу кажутся отличным решением, но в конечном итоге ведут к провалу. 

Разберемся, как распознать подобные антипаттерны, откуда они берутся, и как не дать им уничтожить ваши DevOps-проекты.

 

Объяснение понятия “антипаттерн”

 

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

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

Из огня да в полымя, как говорят.



Антипаттерны. В чем подвох?

 

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

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

 

Антипаттерн “Герой”

 

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

Дабы уложиться в установленные сроки, команда может использовать нестандартный или опасный код. В некоторых сферах индустрии паттерн героя не только используется, но и приветствуется. Быть “героем” проекта - почетное звание. И бывают моменты, когда командам действительно нужны герои.

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

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

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

Как это исправить 

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

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

Вы также можете провести оценку с использованием определенного диапазона, не ожидая от нее абсолютной точности. Многие agile-команды используют числа Фибоначчи для оценок как раз по этой причине; цель такой оценки - смоделировать возможность ее изменения.

 

Антипаттерн непрерывной сборки 

 

DevOps не застрахован от антипаттернов, и непрерывная сборка (Continuous Building, CB) является одним из таких примеров. Это то, что у вас происходит, когда вы настраиваете сервер непрерывной интеграции (Continuous Integration, CI), фактически не имея набора юнит-тестов или выполняя анализ качества кода на базе кода. Вы создаете программное обеспечение при каждой итерации.

(Для уточнения: CB - это подмножество CI, в котором вы выполняете только первую часть CI, а именно сборку. CI включает сборку, модульные тесты и статический анализ качества кода.) 

Антипаттерн CB часто используется с устаревшими приложениями или при переходе команды к Agile и DevOps. Часто все начинается с благих намерений - вы решаете установить CI-сервер и приступить к созданию тестов. Дабы не пугать людей метриками качества кода с кучей проблем, которые вы считаете незначительными, вы решаете установить метрики после того, как почистите код.

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

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

Как это исправить 

Цель CI - обеспечить уверенность в том, что вы можете объединить код, написанный разными членами команды, скомпилировать его и продолжить  работать так, как было задумано автором кода. Это невозможно без тестов, и зачастую юнит-тесты - отличное решение.

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

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



Создание антипаттерна DevOps-отдел

 

Многие организации начинают свой путь в DevOps с добавления нового отдела, который становится посредником между dev’ами и ops’ами. Это превращается в антипаттерн, когда компания перестает объединять dev’ов и ops’ов в единую команду, сохраняя лишь DevOps-отдел.

Создание отдельного DevOps-отдела, используемого в долгосрочной перспективе, является антипаттерном.

Как это исправить 

Когда DevOps-отдел создан, целью должно стать сближение команд dev’ов и ops’ов для сознательного взаимодействия. У DevOps-отдела должно быть четко определенное время жизни как часть этапа трансформации. Рамки его существования должны быть регламентированы, скажем, от одного до трех лет, а по истечении этого времени отдел расформировывается.

По истечении трех лет организация DevOps должна иметь такую структуру. 

Фактически, вся компания должна быть заинтересована в преобразовании, необходимом для того, чтобы потребность в DevOps-отделе отсутствовала. Команды dev’ов и ops’ов должны пересекаться друг с другом, а работа DevOps выполняться на этом пересечении. 



Выборочная автоматизация 

 

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

Как это исправить

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

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

 

Распознать тревожные сигналы

 

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

 

Источник












Состояние технологий виртуализации в 2020 году

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

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

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

Чтобы выяснить это, компания Spiceworks опросила более 530 специалистов, принимающих решения в области ИТ, в компаниях Северной Америки и Европы.

Основные результаты 

  1. Внедрение виртуализации выходит за рамки серверов: в течение следующих двух лет ожидается двузначный рост использования виртуализации настольных компьютеров, приложений, сети, хранилищ и данных.
  2. Переход от массивов хранения к программно-определяемым хранилищам: 25% предприятий планируют использовать программно-определяемые системы хранения данных вместо покупки общих массивов хранения.
  3. Виртуальные окружения перемещаются в облако: в течение следующих двух лет 45% предприятий планируют или рассматривают возможность переноса всей инфраструктуры виртуализации серверов в облако. 
  4. Технология серверного гипервизора рассматривается как продукт: почти треть специалистов, принимающих решения в области ИТ, считает, что технология серверного гипервизора является продуктом.

 

Внедрение технологий виртуализации в бизнесе 

Согласно исследованию Spiceworks, виртуализация серверов повсеместна, ее используют 92% организаций. Однако другим формам виртуализации еще предстоит наверстать упущенное. Среди новых технологий виртуализации наиболее распространенной является виртуализация хранилищ (также называемая программно-определяемым хранилищем) со степенью принятия 40%, за которой следует виртуализация приложений с 39% и технология инфраструктуры виртуальных рабочих столов (VDI) с 32%. Кроме того, виртуализация сети (также называемая программно-определяемой сетью) и виртуализация данных пользуются 30%-ным уровнем принятия. 

Заглядывая в будущее, исследование Spiceworks показало, что более половины организаций планируют использовать виртуализацию хранилищ и виртуализацию приложений в 2021 году. Фактически, ожидается, что виртуализация приложений испытает наибольший рост среди технологий виртуализации, при этом уровень внедрения вырастет с 39% до 56% в 2021 году. Также ожидается двукратный рост использования технологий виртуализации настольных ПК, данных и сетей в течение следующих двух лет. 

 

Внедрение технологии виртуализации в бизнесе

При сравнении ответов данные показывают, что компании с более чем 1000 сотрудников внедряют технологии виртуализации более высокими темпами по всем направлениям. Например, по сравнению с малым бизнесом вдвое больше крупных компаний внедрили виртуализацию приложений (60% крупных компаний против 29% малого бизнеса) и виртуализацию рабочих столов (50% крупных компаний против 24% малого бизнеса).

В перспективе ожидается значительный рост внедрения технологии виртуализации компаниями: к 2021 году 75% компаний планируют использовать виртуализацию приложений, а 69% рассчитывают использовать виртуализацию рабочих столов.

 

Виртуализация хранилищ

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

Согласно выводам Spiceworks, 40% организаций в настоящее время используют технологию виртуализации хранилищ, а еще 12% планируют использовать эту технологию в течение следующих двух лет. Кроме того, четверть компаний заявили, что они будут использовать программно-определяемые хранилища вместо традиционных устройств SAN и NAS. Хотя многие организации согласны с тем, что использование технологии программно-определяемого хранилища является экономически эффективным способом получения выгоды, экономия денег не является основной причиной перехода. 

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

 

 

 

 

 

 

 

Среди компаний, использующих или рассматривающих возможность виртуализации хранилищ, VMware vSAN является наиболее часто используемыми решениями с уровнем внедрения в 34%, за ним следуют Microsoft Storage Spaces Direct (10%), HPE StoreVirtual VSA (10%), Starwind VSA (5%) и Red Hat Gluster (2%). В дальнейшем ранжировка останется в целом такой же, поскольку уровень заинтересованности соответствует текущему ранжированию.

 

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


Однако следует отметить, что HPE постепенно отказывается от продукта StoreVirtual VSA, который не продается с 31 декабря 2019 года, а срок его службы истекает через три года. Нынешние пользователи вынуждены искать альтернативы, в том числе от HPE.

 

Виртуализация рабочего стола 

Согласно исследованию, 32% компаний развернули технологию виртуализации рабочих столов (VDI), и еще 12% планируют внедрить ее к 2021 году. VDI может как повысить эффективность ИТ и помочь организациям защитить конфиденциальные данные, так и дать сотрудникам возможность работать удаленно или с использованием нескольких устройств. Среди компаний, использующих или рассматривающих возможность виртуализации настольных ПК, следующие преимущества считаются главными мотиваторами к покупке:

 

 

 

 

 

 

 

 


Среди компаний, использующих или планирующих использовать технологию виртуальных рабочих столов, 61% в настоящее время используют Microsoft Remote Desktop, что делает его самым популярным решением VDI. За ним следуют Citrix Virtual Desktops (20%) и VMware Horizon View (14%). Несмотря на то, что Microsoft лидирует в области VDI, и Citrix, и VMware могут сократить этот разрыв в течение следующих двух лет, при этом коэффициент использования каждого из решений выражается двузначным числом.

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


Смотря на тенденции внедрения в зависимости от размера компании, можно сделать вывод, что крупные компании и малый и средний бизнес выбирают разные решения VDI. Например, среди компаний, использующих или рассматривающих технологию VDI, 22% крупных компаний используют VMware Horizon View по сравнению с 16% компаний среднего размера и 7% компаний малого бизнеса. Кроме того, 33% крупных компаний используют Citrix Virtual Desktops, по сравнению с 19% компаний среднего размера и 14% предприятий малого бизнеса. Однако Microsoft Remote Desktop противостоит этой тенденции: продукт используют 64% компаний среднего размера и 62% малых компаний по сравнению с 47% крупных компаний. 

Однако самые большие возможности для поставщиков VDI не будут локальными. Хотя текущее использование выражается однозначными числами, многие из них перейдут на облачные решения в течение следующих двух лет. Например, среди компаний, использующих или рассматривающих VDI, 28% рассматривают возможность внедрения недавно запущенного виртуального рабочего стола Windows Azure, 21% рассматривают возможность использования VMware Horizon Cloud, а 10% - использование Amazon Workspaces в течение следующих двух лет. 

 

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

 

Виртуализация сети

Согласно исследованию Spiceworks, 30% предприятий в настоящее время используют технологию сетевой виртуализации, также называемую программно-определяемыми сетями (SDN), и еще 14% планируют внедрить ее в 2021 году. Объясняя растущую популярность технологии, ИТ-руководители называют следующие преимущества в качестве основных причин, по которым организации используют или рассматривают внедрение этой технологии: 

 

 

 

 

 

 

 

Рынок программно-определяемых сетей относительно фрагментирован, и ни один лидирующий на рынке игрок не может значительно обойти остальных участников. Среди компаний, использующих или рассматривающих технологию виртуализации сети, 18% используют VMware NSX, за ними следуют Microsoft SDN с 11% и Cisco ACI с 8%. Также стоит отметить, что 13% компаний используют других поставщиков SDN, ссылаясь на такие бренды, как Ubiquiti UniFi, Cisco Meraki и ZeroTier. В перспективе ожидается, что наиболее популярные SDN-решения сохранят свои текущие позиции: еще 14% организаций рассматривают возможность внедрения VMware NSX и Microsoft SDN в течение следующих двух лет, а 15% рассматривают возможность внедрения Cisco ACI. Следует отметить, что Cisco ACI чаще используется энтерпрайзом (21%) по сравнению со средними (8%) и малыми предприятиями (3%).

 

 

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



Виртуализация серверов

Практически каждый бизнес использует ту или иную форму технологии виртуализации серверов. По текущим данным, бизнес-внедрение виртуализации серверов составляет 92% и вырастет до 97% в течение двух лет. Кроме того, компании доверяют этой технологии выполнение подавляющего большинства услуг, в том числе критически важных. В исследовании Spiceworks респонденты указали, что 77% рабочих нагрузок локальных серверов виртуализированы. 

На насыщенном рынке виртуализации почти треть (31%) специалистов, принимающих решения в области ИТ, считает, что технология серверных гипервизоров является продуктом. Тем не менее, у таких игроков, как VMware, Microsoft и Citrix, все еще есть поле для конкуренции за функциональные возможности в будущем. Например, при оценке серверных гипервизоров, наиболее важными характеристиками продукта ИТ-руководители называют стабильность (86%), надежные возможности аварийного восстановления (63%) и расширенные функции безопасности (40%).

 
Важность факторов, принимаемых во внимание при оценке решений виртуализации серверов

Результаты анализа особенностей и функциональности виртуализации серверов показывают, что наиболее распространенные расширенные возможности, требуемые  бизнесу, включают: широкую доступность (58%), репликацию (57%), виртуальные тома (51%), Live Migration / vMotion (50%) , балансировку нагрузки / распределения ресурсов (50%) и отказоустойчивый кластер (46%). 

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

 

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



Несмотря на то, что существует множество поставщиков систем виртуализации серверов, исследование показало, что рынок гипервизоров для серверов без операционной системы - это в основном гонка между VMware и Microsoft. Среди компаний, использующих или рассматривающих возможность виртуализации серверов, 68% используют VMware vSphere, и 60% используют Microsoft Hyper-V. 

Среди пользователей vSphere 58% платят за vSphere Essentials, Standard или Enterprise, а 22% используют бесплатную версию. А среди пользователей Hyper-V 40% используют автономную версию, а 36% - версию управления доступом на основе ролей. Среди других игроков - Citrix Hypervisor (ранее XenServer) с 10% -ным уровнем внедрения, за которым следуют KVM (7%), Oracle VM Server (4%), Red Hat Virtualization (3%) и Proxmox VE (2%). 

Выбор конкретного решения также зависит от размера компании. Например, энтерпрайз гораздо чаще использует гипервизоры Citrix, Oracle и Red Hat, чем малый и средний бизнес. В то время как малый и средний бизнес с большей вероятностью будут использовать KVM и бесплатную версию vSphere.

 

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

Также стоит отметить, что некоторые организации развернули гипервизоры одновременно от нескольких поставщиков. Например, 27% организаций используют в своих средах и Hyper-V, и vSphere. В будущем это число, вероятно, будет расти, а разрыв между VMware и Microsoft может сократиться. Данные Spiceworks показывают, что еще 12% предприятий рассматривают возможность внедрения VMware vSphere в следующие два года по сравнению с 15%, рассматривающими возможность внедрения Microsoft Hyper-V. 

Опираясь на то, какие версии Hyper-V и vSphere используют компании, результаты показывают, что многие компании используют устаревшие технологии виртуализации. Например, среди пользователей vSphere 30% используют vSphere ESXi 6.7, 47% используют ESXi 6.5 и 24% используют ESXi 6.0, поддержка которого завершилась 12 марта 2020 г. Кроме того, почти треть предприятий (31%) используют неподдерживаемые версии ESXi. При этом VMware не выпускает новые исправления безопасности или исправления ошибок для старых версий.

 

Удовлетворенность клиентов, использующих решения серверного гипервизора 

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

Результаты показывают, что Microsoft и VMware получили высокие оценки удовлетворенности клиентов за стабильность и надежность, что является наиболее важным фактором, который следует учитывать при выборе того или иного решения. Однако платные версии VMware vSphere (Essentials, Standard, Enterprise) обошли конкурентов в других областях, получив высшие оценки удовлетворенности клиентов по всем параметрам, включая надежные возможности аварийного восстановления, расширенные функции безопасности, простой интерфейс управления, комплексную поддержку сторонних интеграций и расширенные возможности автоматизации. 

Microsoft Hyper-V и бесплатная версия VMware vSphere получили высокие оценки за самую низкую совокупную стоимость, но следует отметить, что несколько бесплатных версий не были включены в исследование из-за низкого уровня использования. 

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

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

 

Удовлетворенность пользователей решениями ведущих провайдеров виртуализации серверов 
Среди компаний, использующих в настоящее время каждого из провайдеров

Альтернативы локальным виртуальным машинам

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

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


Источник











 







Что такое GitOps в сравнениии с классическим IaC?

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

Начнем с краткого обзора истории разработки программного обеспечения.

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

Это породило механизм CI/CD-пайплайнов. Он может автоматизировать интеграцию, тестирование и создание кода. С помощью всего одного нажатия вручную вы также можете развернуть веб-сайт и обслуживать своих пользователей в кратчайшие сроки. Это стало возможным с помощью инструментов, которые доступны только для этой цели: инструменты CI/CD. Этот процесс называется DevOps, а использование Git аналогичным образом называется GitOps.

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

Что такое GitOps? Первое, что приходит на ум при использовании термина «GitOps», - «DevOps». DevOps включает в себя разработку операционных инструментов и практик в одном. GitOps - это метод имплементации непрерывной поставки (Continuous Delivery, CD), при котором описание и изменение системы производятся декларативно с использованием системы контроля версий (VCS, обычно Git).

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

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

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

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

 

Разница между IaC и GitOps 

 

Люди часто воспринимают IaC и GitOps как единый термин. Эта сравнительная таблица может помочь прояснить ситуацию:


IaC - это другой процесс, который стоит сам по себе, в то время как GitOps использует преимущества IaC, а также Git в своей системе.

GitOps напрямую связан с IaC, так как мы оперируем сущностями, которые описаны в виде кода. Работа с таким кодом осуществляется с практиками, которые применимы и в разработке (merge request, review, etc).

 

Почему GitOps? 

 

Хотя GitOps является довольно новой моделью, ее использование важно и из-за следующих аспектов:

 

 

 

 

 

 

 

 

 

 

 

Как работает GitOps?

 

Как показано на изображении в разделе выше, GitOps работает за счет комбинации двух вещей: системы IaC и CI/CD пайплайна. Следовательно, необходимо создание механизма, позволяющего начать работу по принципу GitOps. Чтобы понять пайплайн и процесс разработки, необходимо учесть следующие условия:

Инфраструктурный репозиторий и IaC 

В системе, работающей с GitOps, есть два типа репозиториев: 

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

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

Другой компонент этой системы - CI/CD пайплайн. Таким образом, до сих пор в наших руках находятся два компонента:

Теперь нам необходим способ соединения этих двух блоков, чтобы CI/CD знал время, когда запускать тесты и развертывать, то есть запускать пайплайн. Для этого мы разберемся с методами развертывания в GitOps.

 

Развертывания в GitOps

Развертывание на основе push - это первый из двух методов, используемых для развертывания изменений в GitOps. Развертывание на основе push - это традиционная стратегия развертывания, которую мы используем в DevOps, а также с различными инструментами CI/CD. Это простой процесс отправки кода в репозиторий, который переходит в пайплайн сборки. Если код предназначен для изменения конфигурации инфраструктуры, инфраструктурный репозиторий обновляется, и это изменение запускает пайплайн CI/CD. Поскольку мы сосредоточены на окружении, мы не будем рассматривать развертывание кода или управление контейнерами. Предполагается, что развертывание кода приложения известно как пользователь Git. Те же изменения показаны ниже с изображением потока:

На изображении выше показано, что изменение репозитория приложения запускается в пайплайне сборки. Если есть изменение в репозитории окружения, то же самое обновляется и в репозитории. Затем это изменение запускает пайплайн развертывания, и все изменения развертываются. Инструменты, используемые при развертывании на основе push, - это Jenkins, TeamCity, CircleCI, Travis и т.д.

У развертывания на основе push-запросов есть один серьезный недостаток - это дорога с односторонним движением. Изменения в репозитории среды запускают конвейер развертывания и, следовательно, инфраструктуру. Но что, если что-то случится с самой инфраструктурой? У нас нет метода, кроме ручного анализа состояния инфраструктуры и текущего состояния репозитория инфраструктуры или кода время от времени, чтобы знать, все ли в порядке, или нет. Этот недостаток настолько велик, что его нельзя игнорировать. Поэтому развертывание на основе push в GitOps не рекомендуется.

 

Развертывание по запросу - развертывание на основе push + оператор 

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

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

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

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

 

Инструменты для GitOps 

 

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

Данный список можно дополнить следующими инструментами: ArgoCD, FluxCD, Werf.

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

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

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

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


Источник









Как внедряется DevOps?

Прежде чем внедрить у себя DevOps-подход, вам необходимо провести анализ или аудит текущего состояния.

То есть, провести внутри своеобразную инвентаризацию:

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

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

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

Для того, чтобы разобраться, как придти к этому to be:

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

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

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

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

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

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









Что такое AiOps, как это работает?

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

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

Что такое AIOps?

AIOps - (Artificial Intelligence for IT Operations) это термин, введенный Gartner в 2016 году как отраслевая категория для технологии аналитики машинного обучения, которая улучшает аналитику ИТ-операций. Такие операционные задачи включают автоматизацию, мониторинг производительности и корреляцию событий среди прочего. 

AIOps - это сдвиг парадигмы ITOps, необходимый для решения проблем цифровой трансформации.

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

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

Gartner объясняет, как работает платформа AIOps, используя слудующую диаграмму:

 

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

Затем AIOps реализует комплексную стратегию аналитики и машинного обучения в отношении объединенных ИТ-данных. Желаемый результат - аналитика, основанная на автоматизации, которая позволяет постоянно улучшать и исправлять ошибки. AIOps можно рассматривать как как процесс непрерывной интеграции (CI / CD) для основных ИТ-функций.

Для достижения цели постоянного анализа и улучшений AIOps объединяет три различные ИТ-дисциплины: Управление услугами («Engage») Управление эффективностью («Observe») Автоматизация («Act»). AIOps создает некий план, который учитывает, что в новых ИТ-средах должен быть новый подход, основанный на достижениях в области больших данных и машинного обучения.

 

Рассмотрим элементы AIOps, представленные на диаграмме Gartner выше.

 

 

 

 

 



Преимущества интеграции ИИ в цепочку создания ценности: 

 

 

 



Почему предприятиям следует применять AIOps?

 

Преимущества использования этой методологии нового поколения следующие: 

 

 

 

 

 

Заключение 

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

Источник







Зачем вам DevOps?

Что в сущности представляет из себя DevOps?

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

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

В DevOps выделяются три ключевые практики:

Инфраструктура как код - это подход, направленный на то, чтобы вся ваша инфраструктура от самого нижнего уровня (сети, оборудования, количество ресурсов, базы данных, очередь сообщений, кэширующие сервера и т.д.) была описана в виде кода. И не только они, а и все, что выше - application level, то, как разворачиваться ваше приложение, какая у него конфигурация, web-сервера. Это позволяет, во-первых, увеличить скорость: если вам надо, допустим, развернуть еще один сервер, и если уже есть такой же настроенный, с помощью этого подхода вы сможете получить новый, такой же сервер, изменив одну переменную или нажав всего одну кнопку. Во-вторых - контроль изменения. То есть вы знаете, кто, когда и что поменял. Если у вас происходит какой-то инцидент, вы сразу сужаете область поиска до того места, где вы что-то поменяли. Это дает идентичность сред разработки и продакшена, то есть у вас одинаковые версии библиотек, различных сервисов, баз данных, языков программирования, фреймворков. Когда у вас есть полный контроль над вашей конфигурацией, это позволяет уменьшить количество ошибок, которые происходят при внесении изменений в этот процесс.

Непрерывная поставка (CI/CD) 

DevOps, в первую очередь, про скорость, про  time-to-market, то есть про то, насколько быстро мы можем выводить изменения в наших продуктах на рынок без потери функциональных требований, таких как производительность, отказоустойчивость, безопасность.

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

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

Непрерывный мониторинг 

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

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

Второй “кусок”, который входит в эту практику - непрерывное логирование, как мы его называем, или Observability.
Когда у вас сложная система, в которой много компонентов, (например, у типичного банка) запрос, который приходит на веб-сервер, проходит в среднем порядка десяти систем - с веб-сервера он попадает в application, из application-сервера в очередь сообщений, в интеграционную шину, оттуда, например, в obs, оттуда обратно в шину и т.д. И если на каком-то из этапов произошла ошибка, то отыскать ее крайне сложно. Имея централизованную систему логирования, вы весь путь запросто можете пометить маркером конкретного пользователя, и если где-то что-то сломалось, вы достаточно быстро сможете локализовать эту ошибку. Разумеется, это требует установки определенных систем и изменения нескольких практик разработки, но в целом это позволяет в сложных системах понимать, что происходит внутри. Опять же, это дает контроль изменений: в сложной  распределенной системе, где много компонентов, вы сможете понять, на каком этапе какая система сбоит, где ошибка находится, и быстро ее поправить. Плюс вы меряете не только технические показатели, но и бизнес-показатели: после проведения условной маркетинговой кампании вы не ищете вслепую, что же улучшать, а быстро реагируете на то, что происходит с продуктом и на то, как ведут себя пользователи.

К каким кейсам какой из подходов наиболее применим?

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

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

Наиболее популярные инструменты в каждом из подходов:

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







DevOps. На что стоит обратить внимание в 2021 году.

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

  1. Переход на микросервис станет обязательным 

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

  1. Гибрид станет нормой развертывания 

2020 год ускорил удаленную работу, ускорил миграцию в облако, и превратил DevOps из передовой практики в неотъемлемую часть любого бизнеса. Отрасль будет использовать гибрид во многих аспектах.

Во-первых, предприятия перейдут на гибридный вид работы, сочетающие в себе преимущества удаленной работы и совместной работы в офисе.

Во-вторых, бизнес-модели станут гибридными, например конференции.

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

  1. DataOps будет развиваться

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

Пока DevOps настраивает системы только для ведения журнала, мониторинга и оповещения (стеки ELK/EFK, Prometheus/Grafana/Alertmanager и т. д.). Теперь DevOps пора активизировать и использовать доступные данные и метрики для генерирования ценной информации, изучать и применять модели машинного обучения для прогнозирования инцидентов или отключений, разрабатывать автоматизацию, которая учится на данных и прогнозирует возможности для улучшения планирования бюджета. Многие уже начали выделять MLOps/AIOps для этой части.

  1. Chaos Engineering станет основным направлением деятельности

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

  1. GitOps станет нормой

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

GitOps - это способ непрерывной доставки. В частности, это операционная модель для создания облачных приложений, которые объединяют развертывание, мониторинг и управление. Он работает, используя Git как источник истины для декларативной инфраструктуры и приложений. Автоматизированные конвейеры CI/CD развертывают изменения в вашей инфраструктуре, когда коммиты отправляются в Git. Он также использует инструменты для сравнения фактического состояния инфраструктуры с тем, что находится в системе контроля версий, и может предупредить вас, когда есть расхождения.

Конечная цель GitOps - ускорить разработку, чтобы ваша команда могла безопасно вносить изменения и обновления в сложные приложения, работающие в Kubernetes . 

  1. Будет больше миграций на бессерверные версии

В 2021 году будет наблюдаться больше миграций на бессерверные технологии. Если бы контейнеры и оркестраторы были поколением Z, то использующие бессервеные технологии будут поколением Z+. Оплата за использование будет взиматься только во время работы вашего кода. Сравните это с запуском вашего микросервиса в Kubernetes внутри pod`a.

  1. На сцену выходит NoOps

Предвидится появление большего количества управляемых услуг, сокращение наших операций DevOps и сокращение операционных затрат клиентов. Больше бессерверных приложений, больше бессерверных сервисов, таких как Aurora Serverless, Fargate, Amazon S3 и бессерверных статических веб-сайтов на Amazon S3. Amazon ECS/EKS в центрах обработки данных и сервисы управления облаком, которые позволяют сократить объем обслуживания и разработки в центрах обработки данных. Таким же образом, больше облачных принципов и функций перенесено в центры обработки данных.

  1. BizDevOps станет популярным

Движение к оптимизации затрат в отношении архитектур и корпоративных иерархий.

Сосредоточьтесь на гибких облачных архитектурах и инструментах, которые предоставляют возможности, которые когда-то были зарезервированы для крупных компаний в формате, удобной для небольших организаций (Snowflake или Hazelcast против Oracle / Teradata)

FaaS только начинается (без серверов, Lambda и т. д.) - оперативные проблемы решаются, и люди осознают потенциал. 

  1. «Инфраструктура как код» (IaC) поднимется еще выше

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

  1. Автоматизация и Chaos Engineering становятся все более важными 

Все автоматизировано - сборка, развертывание, тестирование, инфраструктура и выпуск.

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

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

  1. Будут стандартизированы облачные подходы

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

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

  1. Безопасность станет главным приоритетом

Определенно на первый план выйдет отслеживание неконтролируемых изменений в вашей инфра-системе с точки зрения DevSecOps.  

  1. Chaos Engineering будет приобретать все большее значение

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

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

Использование журналов при пост-развертывании для проверки успешности выпуска или наличия критических ошибок. Самое главное, что нужно сделать людям, это определить ручные процессы, а затем сделать большой шаг к автоматизации. Развертывание по щелчку, мгновенные журналы для быстрой проверки успеха или неудачи и последующего отката. Затем усложнение возникает из-за зависимостей между службами, и если что-то можно откатить, или требуется дальнейшее тестирование на других службах. Представьте себе 100 микросервисов (они же конвейеры) и даже еще 100 контейнеров.

  1. DevSecOps станет частью DevOps по умолчанию

DevSecOps будет становиться все более и более неотъемлемой частью жизненного цикла разработки программного обеспечения. Реальный подход к безопасности «сдвиг влево» станет новой нормой. В конвейерах CI/CD будет меньше специальных шагов проверки безопасности, и автоматические оповещения о проблемах безопасности и действия на их основе будут частью этапов конвейера. Начиная с IDE разработчика и заканчивая анализом зависимостей и статическим кодом. Компонент программного обеспечения не будет выпущен без надлежащего (автоматического) решения этих проблем.

Источник







Когда стоит задумываться о DevOps?

Существует 4 типовых случая, где DevOps-подход необходим для быстрой и качественной поставки продукта:

Массовые акции

Однажды заказчику нужно было провести онлайн олимпиаду по математике для школьников, при этом олимпиада проходила сразу по всей стране. Соответственно, несколько сотен тысяч человек (школьников) должны были зайти на определенный сайт, там решать математические задачи, и в конце объявлялись результаты этой олимпиады. Чтобы держать такую нагрузку, мы арендовали 20 серверов и взяли два месяца на подготовку. Помимо аренды серверов, нужно было настроить сеть, развернуть диски, настроить операционную систему, поверх нее развернуть приложение, проверить, что все это работает, провести нагрузочное тестирование. И чтобы у нас был какой-то запас, после того как мы проделали все работы, еще 2-3 недели эти сервера стояли и ждали олимпиады, и ничего с ними не происходило. Плюс после того, как олимпиада прошла, надо было поменять профиль серверов, потому что теперь нужно было раздавать дипломы участникам олимпиады, а это совершенно другая нагрузка, и там, условно, даже по-другому должны быть сделаны диски, должен быть большой размер, потому что дипломы были достаточно тяжелыми, и их нельзя было сгенерить на лету (это были pdf-файлы).

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

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

Сезонные нагрузки 

Заказчик - обучающая платформа для корпоративного рынка. 

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

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

Разработка и тестирование

Об этом кейсе расскажем на примере какого-нибудь банка.

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

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

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

Быстрая проверка гипотез

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

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

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

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



Как с нами связаться?

“Экспресс 42”

Телефон +7 (495) 088-42-84
Адрес Москва, ул. Вятская 27с7
Время работы Пн-Вс: 10:00 - 19:00

Получить консультацию


Регистрация

Запишитесь на вебинар

Фамилия, Имя *
E-mail *
Контактный телефон *
Должность
Расчет стоимости
К сожалению, невозможно указать универсальные расценки на анализ и внедрение DevOps практик,
потому что трудозатраты зависят от целого ряда факторов.

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

Имя *
E-mail *
Контактный телефон *
Комментарий
Оформление заявки

Давайте обсудим ваш проект
и разберемся, как мы можем вам помочь

Имя *
E-mail *
Контактный телефон *
Комментарий
Бесплатная консультация

Остались вопросы?
Мы перезвоним и ответим на них!

Имя *
Контактный телефон *
Заголовок отзыва
Политика конфеденциальности
Политика конфиденциальности персональных данных

Настоящая Политика конфиденциальности персональных данных (далее – Политика конфиденциальности) действует в отношении всей информации, которую сайт Экспресс 42, (далее – Экспресс 42) расположенный на доменном имени express42.com (а также его субдоменах), может получить о Пользователе во время использования сайта express42.com (а также его субдоменов), его программ и его продуктов.

1. Определение терминов

1.1 В настоящей Политике конфиденциальности используются следующие термины:

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

1.1.2. «Персональные данные» - любая информация, относящаяся к прямо или косвенно определенному, или определяемому физическому лицу (субъекту персональных данных).

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

1.1.4. «Конфиденциальность персональных данных» - обязательное для соблюдения Оператором или иным получившим доступ к персональным данным лицом требование не допускать их распространения без согласия субъекта персональных данных или наличия иного законного основания.

1.1.5. «Сайт Экспресс 42» - это совокупность связанных между собой веб-страниц, размещенных в сети Интернет по уникальному адресу (URL): express42.com, а также его субдоменах.

1.1.6. «Субдомены» - это страницы или совокупность страниц, расположенные на доменах третьего уровня, принадлежащие сайту Экспресс 42, а также другие временные страницы, внизу который указана контактная информация Администрации

1.1.5. «Пользователь сайта Экспресс 42 » (далее Пользователь) – лицо, имеющее доступ к сайту Экспресс 42, посредством сети Интернет и использующее информацию, материалы и продукты сайта Экспресс 42.

1.1.7. «Cookies» — небольшой фрагмент данных, отправленный веб-сервером и хранимый на компьютере пользователя, который веб-клиент или веб-браузер каждый раз пересылает веб-серверу в HTTP-запросе при попытке открыть страницу соответствующего сайта.

1.1.8. «IP-адрес» — уникальный сетевой адрес узла в компьютерной сети, через который Пользователь получает доступ на Экспресс 42.

1.1.9. «Товар » - продукт, который Пользователь заказывает на сайте и оплачивает через платёжные системы.

2. Общие положения

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

2.2. В случае несогласия с условиями Политики конфиденциальности Пользователь должен прекратить использование сайта Экспресс 42 .

2.3. Настоящая Политика конфиденциальности применяется к сайту Экспресс 42. Экспресс 42 не контролирует и не несет ответственность за сайты третьих лиц, на которые Пользователь может перейти по ссылкам, доступным на сайте Экспресс 42.

2.4. Администрация не проверяет достоверность персональных данных, предоставляемых Пользователем.

3. Предмет политики конфиденциальности

3.1. Настоящая Политика конфиденциальности устанавливает обязательства Администрации по неразглашению и обеспечению режима защиты конфиденциальности персональных данных, которые Пользователь предоставляет по запросу Администрации при регистрации на сайте Экспресс 42, при подписке на информационную e-mail рассылку или при оформлении заказа.

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

3.2.1. фамилию, имя, отчество Пользователя;

3.2.2. контактный телефон Пользователя;

3.2.3. адрес электронной почты (e-mail)

3.2.4. место жительство Пользователя (при необходимости)

3.2.5. адрес доставки Товара (при необходимости) 3.2.6. фотографию (при необходимости).

3.3. Экспресс 42 защищает Данные, которые автоматически передаются при посещении страниц:

- IP адрес;

- информация из cookies;

- информация о браузере

- время доступа;

- реферер (адрес предыдущей страницы).

3.3.1. Отключение cookies может повлечь невозможность доступа к частям сайта , требующим авторизации.

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

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

4. Цели сбора персональной информации пользователя

4.1. Персональные данные Пользователя Администрация может использовать в целях:

4.1.1. Идентификации Пользователя, зарегистрированного на сайте Экспресс 42 для его дальнейшей авторизации, оформления заказа и других действий.

4.1.2. Предоставления Пользователю доступа к персонализированным данным сайта Экспресс 42.

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

4.1.4. Определения места нахождения Пользователя для обеспечения безопасности, предотвращения мошенничества.

4.1.5. Подтверждения достоверности и полноты персональных данных, предоставленных Пользователем.

4.1.6. Создания учетной записи для использования частей сайта Экспресс 42, если Пользователь дал согласие на создание учетной записи.

4.1.7. Уведомления Пользователя по электронной почте.

4.1.8. Предоставления Пользователю эффективной технической поддержки при возникновении проблем, связанных с использованием сайта Экспресс 42.

4.1.9. Предоставления Пользователю с его согласия специальных предложений, информации о ценах, новостной рассылки и иных сведений от имени сайта Экспресс 42.

4.1.10. Осуществления рекламной деятельности с согласия Пользователя.

5. Способы и сроки обработки персональной информации

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

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

5.3. Персональные данные Пользователя могут быть переданы уполномоченным органам государственной власти Российской Федерации только по основаниям и в порядке, установленным законодательством Российской Федерации.

5.4. При утрате или разглашении персональных данных Администрация вправе не информировать Пользователя об утрате или разглашении персональных данных.

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

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

6. Права и обязанности сторон

6.1. Пользователь вправе:

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

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

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

6.2. Администрация обязана:

6.2.1. Использовать полученную информацию исключительно для целей, указанных в п. 4 настоящей Политики конфиденциальности.

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

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

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

7. Ответственность сторон

7.1. Администрация, не исполнившая свои обязательства, несёт ответственность за убытки, понесённые Пользователем в связи с неправомерным использованием персональных данных, в соответствии с законодательством Российской Федерации, за исключением случаев, предусмотренных п.п. 5.2., 5.3. и 7.2. настоящей Политики Конфиденциальности.

7.2. В случае утраты или разглашения Конфиденциальной информации Администрация не несёт ответственность, если данная конфиденциальная информация:

7.2.1. Стала публичным достоянием до её утраты или разглашения.

7.2.2. Была получена от третьей стороны до момента её получения Администрацией Ресурса.

7.2.3. Была разглашена с согласия Пользователя.

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

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

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

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

7.6. В отношение текстовых материалов (статей, публикаций, находящихся в свободном публичном доступе на сайте Экспресс 42) допускается их распространение при условии, что будет дана ссылка на Экспресс 42.

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

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

7.9. Администрация не несет ответственность за какую-либо информацию, размещенную пользователем на сайте Экспресс 42, включая, но не ограничиваясь: информацию, защищенную авторским правом, без прямого согласия владельца авторского права.

8. Разрешение споров

8.1. До обращения в суд с иском по спорам, возникающим из отношений между Пользователем и Администрацией, обязательным является предъявление претензии (письменного предложения или предложения в электронном виде о добровольном урегулировании спора).

8.2. Получатель претензии в течение 30 календарных дней со дня получения претензии, письменно или в электронном виде уведомляет заявителя претензии о результатах рассмотрения претензии.

8.3. При не достижении соглашения спор будет передан на рассмотрение Арбитражного суда г. Москва.

8.4. К настоящей Политике конфиденциальности и отношениям между Пользователем и Администрацией применяется действующее законодательство Российской Федерации.

9. Дополнительные условия

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

9.2. Новая Политика конфиденциальности вступает в силу с момента ее размещения на сайте Экспресс 42, если иное не предусмотрено новой редакцией Политики конфиденциальности.

9.3. Все предложения или вопросы касательно настоящей Политики конфиденциальности следует сообщать по адресу: input@express42.com

9.4. Действующая Политика конфиденциальности размещена на странице по адресу https://express42.com/user-agreement

Обновлено: 01 Июля 2017 года

г. Москва, ООО "Экспресс 42", ОГРН 1127746121535

Спасибо за заявку!


Спасибо, ваши данные успешно отправлены!
Мы свяжемся с вами как можно скорее