Криптотрейдинг: прибыльная торговля криптовалютой.
Июн 4, 2019
47 Views
Комментарии к записи DevOps — Разработка и эксплуатация отключены

DevOps — Разработка и эксплуатация

Written by
Биткоин: краткое руководство

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

В старые времена решения были связаны с получением правильной технологии. Ключ был технология, решение было технология, и бизнес ожидал и заплатил за технологию. Времена изменились. Ну, по крайней мере, для тех из нас, кто обращает на это внимание. В настоящее время технология не является серьезной проблемой. Технически у нас менее сложный мир. За прошедшие годы мы поняли, что технология — это, по сути, система обработки, хранения, работы в сети и системы хранения данных. Мы использовали виртуализацию до совершенства. Мы понимаем, что горизонтальное масштабирование «лучше», чем вертикальное, и что мы можем с большей легкостью предоставлять PMNS в конвергентных и гиперконвергентных продуктах, которые также содержат программное обеспечение. Мы автоматизировали многие ключевые операции, чтобы вы могли сократить время и затраты.

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

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

Создание и доставка приложений

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

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

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

Почему это?

Во всех информационных системах, от инфраструктуры центра обработки данных до облачных приложений, существует одна проблема, которая влияет на бесперебойную совместную работу проекта, а именно «бункеры активности».

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

Дизайн решения и разработка приложения означали, что появление Lean и Agile было действительно эффективным способом действий, и все же бункеры остались. Компании управляли Agile, но они поддерживали режим работы в бункере. Странно, когда вы думаете об этом. Agile означает гибкость и способность меняться без травм. Бункер — это «дно» с высокими бортами, что делает изменение очень трудным. По сути, Agile и бункеры взаимодействовали друг с другом и препятствовали переменам. Все еще так.

силос

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

Разработчик приложения создает приложение на основе концепции или запроса. Техническому сервисному архитектору (TS) предлагается создать проект высокого уровня (HLD) для инфраструктуры приложений. TS Architect передает HLD архитектору проекта для проверки проекта. Архитектор проекта передает окончательный вариант HLD обратно в TS Architect. TS Architect объясняет дизайн создателя приложения и включает в себя все элементы, которые могут представлять приложение. Обычно это делается в отрыве от других экспертов. HLD подписан, куплен кем-то или другим, и разработчик проекта предпринимает действия, связанные с должной осмотрительностью, перед созданием низкоуровневого проекта (LLD или Build Doc) для инфраструктуры приложений. Архитектор проекта должен посетить различных тематических экспертов (МСП) в области вычислений, сетей, систем хранения данных и аварийного восстановления (DR), чтобы выяснить, какие технологии и требования должны быть найдены в LLD. Подробная информация о протоколах, маршрутизации, правилах безопасности и правилах брандмауэра может быть сложной и может негативно повлиять на приложение, если они не будут тщательно спланированы. Чтобы получить это право, вам следует проконсультироваться с экспертом по анализу воздействия, чтобы убедиться, что проблемы безопасности и соответствия, если они существуют, могут быть решены или смягчены. Большинство приложений развертываются в виртуальных инфраструктурах, которые требуют привлечения экспертов по виртуализации для поддержки технологий совместного использования и автоматизации. Таким образом, архитектор проекта должен проконсультироваться со многими различными технологическими бункерами / экспертами. Во время этого действия Архитектор должен постоянно возвращаться к разработчику приложения, чтобы проверить, не приведет ли то, что запланировано в инфраструктуре, к «повреждению» дизайна приложения и не сделает приложение неэффективным после реализации. Наконец, необходимо обеспечить Service Wrap для поддержки приложения и удовлетворения нефункциональных требований в соглашениях об уровне обслуживания (SLA). Двадцать человек могут участвовать в процессе. Я не включил тестирование и разработку, потому что они обычно ждут до конца основного процесса вместе с пользовательским приемочным тестом (UAT). Иногда есть отдельная команда, которая поддерживает эту часть, иногда она выполняется Операциями. Разработка приложений также включает в себя уровни зависимости, которые обеспечивают промежуточные уровни и уровни базы данных. Может случиться так, что при включении этих услуг потребуется участие гораздо больше людей. Это правда, что каждое МСП является частью бункера. Конструкция должна согласовываться со всеми бункерами. Некоторые полезны, другие нет, и есть много причин, почему нет! это может быть ответ на все вопросы и предлагаемые решения.

Все бункеры и все вовлеченные лица делают весь проект медленным и дорогим. Аналогия — игра змей и лестниц.

DevOps

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

Что нужно сделать, чтобы удалить силосы:

  • Изменить рабочую культуру

  • Удалить стены между сборками (и удалить силосы)

клавиатура:

  • Коммуникация, сотрудничество, интеграция и обмен информацией

Это легко сказать, и это трудно сделать.

Большинству МСП нравится хранить свою информацию при себе. Это касается не всех, а многих. Это часть традиционной культуры, которая развивалась на протяжении многих лет. Трудовые практики затрудняют изменения. Управление изменениями — одна из самых сложных задач, которые может взять на себя любая компания. Сопротивление будет защищено, потому что людям важно отказаться от чего-то, чтобы получить что-то. Нужно объяснить, что такое прибыль. Люди изменят свое отношение и поведение, но вы должны дать им действительно веские причины для этого. Я обнаружил, что проведение многопрофильных семинаров для МСП оказалось эффективным способом поощрения обмена информацией и разрушения этих «стен».

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

Укажите конкретные измеримые цели:

  • Внедрение «плоской» организационной структуры. Если мы поддерживаем горизонтальное масштабирование, почему не горизонтальные организации?

  • Каждый App-Dev или Solution-Dev — это проект, и команда универсальна в разных дисциплинах.

  • Осуществление текущего обмена информацией и обзорами

  • Убедитесь, что все зарегистрировались в DevOps и понимают парадигму

Что такое DevOps

Как парадигма Облака, это просто еще один способ что-то сделать. Как облако имеет разные определения в зависимости от того, о ком вы говорите в данный момент.

Википедия дает: Поскольку DevOps — это культурное изменение и сотрудничество между разработкой и эксплуатацией, не существует одного инструмента DevOps, точнее, набора или «набора инструментов», состоящего из множества инструментов. В общем, инструменты DevOps относятся к одной или нескольким категориям, что отражает процесс создания и доставки программного обеспечения.

Я не думаю, что это все DevOps. Делается вывод, что DevOps занимается исключительно созданием приложений и операций. Я не верю этому. Я считаю, что DevOps — это парадигма, которая, как и другие «стандарты» и парадигмы ИТ, подходит для всех информационных систем, а не только для приложений. Устраняя разделение между каждой практикой в ​​цепочке и привлекая всех ключевых игроков с первого дня, в составе объединяющей и совместной команды, цикл разработки приложений и проектирования решений становится непрерывным процессом, который не нужно перенаправлять для консультации с любым необходимым экспертом. Никто не должен бросать документ через стену другой команды. Каждый документ написан как часть процесса сотрудничества и должен сделать документ более точным и эффективным. Представьте, что команда проекта всегда находится в одной комнате, от идеи до реализации, и каждый эксперт всегда доступен для комментариев и дополнений на каждом этапе проекта. Гораздо лучше, чем традиционный метод, в котором может потребоваться несколько дней, чтобы найти ответ на простой вопрос или даже найти подходящего человека, чтобы задавать вопросы.

Мантра: расти, тестировать, внедрять, отслеживать, отправлять отзывы и так далее. Звучит ориентированно на приложение. Фактически это может повлиять на разработку любого ИТ-решения. Как и ITIL, TOGAF и эталонная модель из семи уровней, она может использоваться для всех видов ИТ-деятельности, от разработки до поддержки. DevOps ставит нас всех на одной странице от начала до конца.

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

Article Categories:
Криптовалюта
Как устроен блокчейн

Comments are closed.