Digital Enterprise

Сохранение контроля

Можно наглядно наблюдать, как компании сталкиваются со проблемой управления сложностью современных приложений. Создание ПО собственной разработки для внутренних нужд, для реализации ключевых бизнес-процессов компании, чаще всего основывается на принципе микросервисной архитектуры. Эта метаструктура приложения очень далека от представления последнего в виде некоторого монолитного объекта, обладающего определенными характеристиками. При использовании микросервисной архитектуры приложение конструируется в виде облака (хотел написать – массива, но слово “облако” гораздо лучше описывает картину) маленьких приложений, хорошо выполняющих только одну функцию. Отдельные экземпляры запущенных микросервисов абсолютно изолированы друг от друга, для их создания и/или удаления используются автоматические средства доставки, контейнеры. Каждый из таких сервисов имеет свои требования…

Плановый простой в контексте SLA

Интересно наблюдать, как под воздействием накопленного опыта развиваются интересы и трансформируются приоритеты коллег, с кем выпадает удовольствие работать и не меньшее удовольствие обмениваться опытом в рамках курсов обучения, периодически проходящих у нас в Cleverics. Недавно вышло так, что близкие по содержанию вопросы поднимались слушателями курса “Управление изменениями и релизами ИТ-услуг” (ITIL RCV) и коллегами по проекту. Вопросы касались планирования простоев услуг, необходимых для внедрения изменений. Один из вопросов был следующий: нужно ли, согласно хорошим практиками, учитывать внеплановые простои, во время которых внедрялись изменения, трактуемые бизнесом как “безотлагательные”, в отчётности? Отвечу в соответствии со своим пониманием. Если коротко – в отчётность нужно…

Артём Мукосеев, 4 декабря 2017, последний комментарий 4 декабря 2017

Пост на вечную тему, который должен написать каждый

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

Андрей Шилов, 30 ноября 2017, последний комментарий 30 ноября 2017

«Правильная» структура команд для DevOps

Вопрос построения DevOps неизбежно и достаточно быстро упирается в организацию команд. Недаром наша недавняя публикация на портале “Мы должны убить DevOps” вызвала неоднозначную реакцию у читателей. Но, пожалуй, ключевое в данном случае – сам факт наличия реакции. Также показательно бьёт все рекорды регистрация на вебинар “Изменения в ИТ-подразделении при движении в сторону DevOps”. Получается, что при всем кажущемся многообразии различных материалов, действительно полезных – где воды поменьше, а полезных мыслей побольше – среди них мало. Чем больше на разные лады повторяют с подачи гугл-переводчика про силосы (силосы?!) и о том, что “Dev и Ops должны любить друг друга”, тем больше…

Новостной поток, 29 ноября 2017, последний комментарий 30 ноября 2017

9 человеческих факторов, отравляющих DevOps

Оригинал 9 ‘People Problems’ Plaguing DevOps, автор Синтия Харви (Cynthia Harvey) Когда ИТ-подразделения переходят на подход DevOps, они часто сталкиваются с непростыми организационными и культурными проблемами. Любой заслуживающий внимания DevOps-эксперт скажет вам, что простое использование инструментов DevOps не превратит вашу ИТ-группу в DevOps-команду. Напротив, вашей организации необходимы культурные изменения. И, увы, менять людей намного сложнее, чем технологии. При первом внедрении DevOps большинство ИТ-групп сталкиваются с проблемами, связанными с культурой и/или структурой их организации. Эти препятствия могут сделать затруднительными для организации обретение гибкости и взаимодействия между разработчиками и операционным отделом, которые являются отличительными чертами подхода DevOps. К счастью, эти препятствия можно…

Понятие продукта в контексте Agile и ITSM

В редакцию портала поступил вопрос: Здравствуйте! Помогите, пожалуйста, разобраться с понятием продукта в контексте синхронизации двух концепций: гибкой разработки ПО и ITSM.С одной стороны, в компании начали применять Agile-подход и инструменты SCRUM при разработке продуктов (пример продукта ─ мобильное приложение для покупателей). С другой стороны, ИТ пытается разговаривать с бизнесом в терминах ИТ-услуг. У участников этих коммуникаций возникает сложность в понимании основных терминов и разницы понятий «информационная система», «продукт», «ИТ-услуга», «бизнес-процесс». А также в понимании взаимоотношений различных ролей и возможности их совмещения, например, владельца продукта и владельца услуги. С определением ИТ-услуги все понятно (ITIL нам в помощь), а с продуктом…

Новостной поток, 27 ноября 2017, последний комментарий 1 декабря 2017

Запросы или потребности?

Во время обсуждения взаимодействия ИТ и бизнеса на одном из последних курсов возникла дискуссия на тему бизнес-ориентированности ИТ. По мере обсуждения были выявлены две точки зрения на то, что такое готовность ИТ помогать бизнесу. ИТ-подразделение должно качественно отрабатывать запросы бизнеса ИТ-подразделение должно удовлетворять потребности бизнеса «Мы (ИТ) должны выявлять потребности бизнеса, те задачи, которые бизнес пытается решить, и попытаться помочь ему в этом» – говорили одни. «Мы (ИТ) должны чётко отрабатывать ТЗ (техническое задание). Мы не можем «фантазировать». Да и как, скажите на милость, в случае отсутствия чёткого ТЗ фиксировать целевую картину в договоре?» – возражали другие. В этой связи…

Игорь Гутник, 26 ноября 2017, последний комментарий 27 ноября 2017

Какова доля продуктивного труда современного разработчика

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

Вопрос из зала, 23 ноября 2017, последний комментарий 27 ноября 2017

Мы должны убить DevOps

DevOps был действительно трансформирующим подходом, который позволял командам разрабатывать, развёртывать и обновлять программное обеспечение быстро, легко и без традиционных разногласий (или стычек) между стражами райских врат, операционной командой, и наступающими ордами разработчиков. Он возглавил волну инноваций в автоматизации, мониторинге и создании ПО, способствовал практически повсеместному использованию виртуализации и контейнеризации и был, в широком смысле, глотком свежего воздуха в отрасли, последним крупным изменением подходов в которой была методология Agile. Я горжусь работой, которую проделал в сфере DevOps, и я провел много времени, усердно внушая людям веру в его чудеса. А теперь для DevOps пришло время умереть. Пока вы не отправились рассказывать…

Новостной поток, 22 ноября 2017, последний комментарий 27 ноября 2017

Black Friday: “Основы ITIL” по рекордно низкой цене

Только в черную пятницу 24 ноября дистанционный курс “Основы ITIL” (самостоятельное изучение) будет стоить всего 1000 руб. Узнать больше и зарегистрироваться можно на сайте Cleverics. Дистанционный курс “Основы ITIL” позволяет самостоятельно освоить основные принципы и понятия управления ИТ-услугами, узнать всё самое важное о процессах, описанных в пяти книгах ITIL, и проверить усвоение каждой темы с помощью контрольных вопросов. Доступ к материалам курса предоставляется на 90 дней, и в течение этого времени можно использовать материалы успешно пройденных разделов в качестве источника справочной информации. Для доступа к материалам курса достаточно иметь устройство с выходом в Интернет, установка специального ПО не требуется. Материалы…

Новостной поток, 22 ноября 2017, последний комментарий 27 ноября 2017

Как правильно распорядиться ваучером

Опыт взаимодействия наших менеджеров с кандидатами, сдававшими или планирующими сдавать экзамены ITIL®, PRINCE2® показывает, что есть запрос на более подробную информацию о процедуре прохождения экзамена через PEOPLECERT с использованием ваучера и технических требованиях к системе, на которой будет сдаваться экзамен. Ваучер, напомню, позволяет сдавать экзамен где угодно, хоть дома (при соответствии места требованиям, о которых ниже) и когда угодно (в пределах срока действия ваучера). Нужно сразу предупредить о том, что компания PEOPLECERT, которая с 01.01.2018 станет единственным институтом, обеспечивающим приём экзаменов AXELOS (ITIL, PRINCE2 и проч.) предоставляет пошаговые инструкции для всех этапов сдачи экзамена (от регистрации, до собственно прохождения экзамена)….

Игорь Гутник, 17 ноября 2017, последний комментарий 20 ноября 2017

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

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