Начало пути к автоматизации может показаться непосильной задачей. Мы часто слышим вопросы от наших клиентов, например: «С чего мне начать?» или «Как я могу убедиться, что с самого начала строю платформу правильно?» Всем отличные вопросы. Тем не менее путешествие — ключевое слово, когда дело доходит до автоматизации вашей сети. В этом сообщении в блоге я подробно расскажу о некоторых ключевых выводах, которые я обнаружил в последние несколько месяцев в рамках усилий по развитию бизнеса в Network to Code, и о том, как наши клиенты успешно внедряют эти изменения в своих средах.
Один из общих разговоров, которые мы ведем с новыми и существующими клиентами, связан с повторяемыми вручную рабочими процессами. Например, частый случай использования, с которым мы часто сталкиваемся, — это запрос на изменение политики брандмауэра. Во многих организациях есть ручной процесс, который затрагивает несколько команд и источников данных и может занять несколько недель. В сочетании с десятками запросов в неделю / месяц это создает огромную нагрузку на команду инженеров. Более того, эта проблема напрямую мешает бизнесу, поскольку сильно влияет на скорость выхода на рынок. Вариант использования запроса на изменение может показаться довольно простым с точки зрения решения. Однако, начав снимать слои, вы понимаете, что, вероятно, потребуется несколько инструментов. Например, ITSM может быть отправной точкой для отправки и отслеживания запроса,
Кроме того, данные, необходимые для автоматизации изменений, могут находиться в различных системах или таблицах. Вдобавок ко всему, для индивидуальной работы часто требуются базовые знания программирования для интеграции различных API-интерфейсов продуктов. Как насчет определения того, какие брандмауэры попадают в область действия изменения — следует ли делать вывод на основе данных об изменении, представленных в заявке? Часто именно здесь проявляется подавляющая эмоция, когда выявляются пробелы в знаниях о ресурсных продуктах.
Часто есть несколько способов подойти к вариантам использования с помощью методологий покупки или сборки. Мы видели, как большинство клиентов используют гибридный подход, а также используют сообщество открытого исходного кода для получения рекомендаций. Я бы сказал, что это действительно лучший метод, поскольку создание надлежащей платформы позволяет организациям работать быстрее и автоматизировать другие области сети.
Кроме того, готовые инструменты часто удовлетворяют только часть рабочего процесса, тогда как создание платформы позволяет настраивать вводимые данные, создавая более точные данные для сквозной автоматизации, специфичные для нужд организации.
С чего бы мне начать?
Все организации имеют уникальную среду, поэтому этап оценки является ключевым для определения потребностей организации. Вы можете быть незнакомы или даже не знать о существующих в вашей организации инструментальных средствах автоматизации, оркестрации и DevOps, но после проведения серии интервью вы можете обнаружить, что команда разработчиков приложений (например) уже использует определенный набор инструментов для автоматизации выделения ресурсов, документацию или то, что требует их рабочий процесс.
На этапе оценки любого пути автоматизации сети также выявляются ключевые проблемы, связанные с процессом. Мы часто обнаруживаем, что отделы имеют совершенно разные взгляды на то, как работает процесс или как он должен работать. Оценка позволяет бизнес-подразделениям говорить о рабочем процессе, который, как ни странно, нечасто происходит перед оценкой. Если третья сторона задает правильные вопросы, это способствует успешным результатам.
Как я могу убедиться, что с самого начала строю платформу правильно?
Обратиться за помощью к специалистам — отличный способ начать. Вместо того чтобы изобретать колесо, обратитесь к организации, которая имеет бесчисленные часы опыта внедрения рабочих процессов автоматизации в аналогичных средах. Другой вариант — использовать сообщество разработчиков ПО с открытым исходным кодом, чтобы задавать вопросы и находить отличные статьи и видео по определенной теме. Как правило, люди готовы помочь или, по крайней мере, указать вам правильное направление.
Как я могу доказать руководству, что нам нужна автоматизация?
Многие организации используют инструменты для построения графиков данных, таких как количество заданий, проверки соответствия производительности труда, данные о местоположении и т. д. Но когда дело доходит до автоматизации сети, участие руководства не всегда гарантировано. Важно постоянно тестировать и собирать легко усваиваемые данные. Целевые данные позволяют ключевым заинтересованным сторонам сопоставлять данные и извлекать часы или доллары, сэкономленные на встроенной платформе автоматизации.