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






Новости







Правда ли, что HR смотрит резюме всего 20 секунд?

Один день из рабочей жизни рекрутера состоит из 3-4 собеседований, организации технических интервью, написания писем кандидатам и поиска. Что это означает? Рекрутер использует все доступные ему каналы с резюме: HH, habr, сообщества в телеграме, LinkedIn и еще много всего. За час опытный рекрутер может отсмотреть несколько десятков резюме и выбрать из них те, что представляют интерес по вакансии.

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

Если, все-таки, "профиль наш", то внимание заостряется уже на деталях. Например, настраивал ли тот же мониторинг кандидат с нуля и самостоятельно, или лишь принимал участие? На текущей позиции проработал пару месяцев, или построил карьеру и успел хорошо прокачаться. На это уходит дополнительно еще секунд 10-15.

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

"И что нам с этим делать", — резонно спросите вы. "Использовать в своих интересах и тщательно составлять резюме", — безапелляционно ответит Рушана.

Что делать?

  1. Важно посмотреть на резюме глазами рекрутера/лида/менеджера и отразить все максимально прозрачно.

  2. Точно описать задачи и сопутствующие технологии, с которыми работали (например, настраивал сбор логов с помощью ELK-стека).

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

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

  5. Заполнить блок "Обо мне", где можно указать, какие задачи/проекты вам интересны в будущем, и в какую сторону вы планируете развиваться.

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

Кстати, если вы хотите больше советов о том, как писать резюме, готовиться и проходить собеседования, то смотрите вот это видео  подробными инструкциями:
httсps://youtu.be/856IAFo59LM

Если у вас есть вопросы к нашим рекрутерам, пишите нам на почту и в телеграм:

rushana@express42.com

@Razrushana







Планирование Service Mesh: ключевые аспекты

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

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

 

Зачем нужна архитектура Service Mesh? 

 

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

Определение и достижение ценностей бизнеса

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

 

Планирование внедрения Service Mesh

 

Планирование интеграции Service Mesh начинается с продуманной стратегии. Без стратегии поток задач, необходимых для завершения перехода, может показаться бесконечным, задавить объёмом и увести проект от намеченной цели - достижения ценностей бизнеса. 

В рамках этой статьи мы сосредоточимся на четырех из пяти основных аспектов реализации Service Mesh: 

  1. Определение бизнес-возможностей 

  2. Организационные действия 

  3. Управление 

  4. Операции и безопасность

 

Определение бизнес-возможностей 

 

Первым шагом в процессе трансформации является определение составляющих вашего бизнеса. Эти возможности затем определяются как микросервисы на платформе Service Mesh. Этот шаг помогает предотвратить создание дублирующих сервисов и сопровождается созданием политик управления жизненным циклом (подробнее об этом позже). Эти политики взаимосвязаны и определяют бизнес-процессы с общим видением проекта.

Разработка эталонной архитектуры

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

 

Организационные действия 

 

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

Рассмотрим две самых важных подструктуры.

Центр компетенций

Центр компетенций предоставляет компании руководство по созданию микросервисов, реализующих определенные бизнес-возможности, необходимые для платформы Service Mesh. 

В его задачи входит:

 

Подразделы по сферам компетенций

Формирование подразделов по сферам компетенций помогает установить и распространить стандарты и процедуры управления, упомянутые выше. 

Эти стандарты и процедуры управления затем доводятся до команд в следующих областях: 

 

Создание модели управления 

 

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

Политики управления микросервисами 

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

Обеспечение соблюдения политик для сети

Установка и обеспечение соблюдения регламентов, регулирующих использование сервисов, денежных ресурсов и SLA - еще один важный шаг в планировании архитектуры Service Mesh. Независимо от вида (будь то обеспечение качества сервиса или шифрования), политики должны разрабатываться и соблюдаться для обеспечения успеха проекта. 

Политики безопасности:

Вопросы эксплуатации и безопасности 

 

Переход на архитектуру Service Mesh позволяет согласовать операционные регламенты в соответствии с требованиями безопасности. Это также позволяет воспользоваться преимуществами DevOps практик, поскольку инфраструктура теперь - это код. Безопасность перестаёт быть тем, о чём думают в последнюю очередь, даже на уровне абстракции виртуализированных микросервисов. Для создания и поддерживания уровня метрик на этапе трансформации необходимо обеспечить более строгое соблюдение операционных политик.

Управление конфигурацией 

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

Управление релизами 

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

Разработка метрик

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

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

 

Основные этапы реализации Service Mesh

 

В процессе перехода на архитектуру Service Mesh мы обычно обеспечиваем выполнение следующих процессов для гарантии генерации ценности для бизнеса в течение 6 месяцев:



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

 

Ключевые выводы этой статьи следующие:

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

 

Источник









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

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

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

  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, оттуда обратно в шину и т.д. И если на каком-то из этапов произошла ошибка, то отыскать ее крайне сложно. Имея централизованную систему логирования, вы весь путь запросто можете пометить маркером конкретного пользователя, и если где-то что-то сломалось, вы достаточно быстро сможете локализовать эту ошибку. Разумеется, это требует установки определенных систем и изменения нескольких практик разработки, но в целом это позволяет в сложных системах понимать, что происходит внутри. Опять же, это дает контроль изменений: в сложной  распределенной системе, где много компонентов, вы сможете понять, на каком этапе какая система сбоит, где ошибка находится, и быстро ее поправить. Плюс вы меряете не только технические показатели, но и бизнес-показатели: после проведения условной маркетинговой кампании вы не ищете вслепую, что же улучшать, а быстро реагируете на то, что происходит с продуктом и на то, как ведут себя пользователи.

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

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

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

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

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

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

“Экспресс 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

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


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