Развертывание и управление этим сайтом стало кошмаром. Развертывание, от разработки до контроля качества и подготовки к производству, занимает пару дней. У нас много ошибок, и это требует большого количества ручного труда. У нас часто есть файлы конфигурации, которые были обновлены или изменены неправильно, и затем весь сайт на этом веб-сервере выходит из строя.
Я один из разработчиков, отвечающих за разработку системы. В настоящее время отсутствует автоматизация, нулевое автоматическое тестирование, а процесс развертывания включает в себя вход на серверы с терминальным сервером и ручное изменение настроек IIS, обновление файлов конфигурации и тому подобное. Документация по аварийному восстановлению оставляет желать лучшего.
Я хотел бы дать возможность команде, которая занимается операциями с серверами, успешно развернуть и поддерживать приложение, над которым я работаю. Так что отчасти по очень эгоистичным причинам я хочу, чтобы они преуспели.
Мне нужно какое-то направление; о том, какие конкретные вопросы я могу им задать или предложения, которые я могу сделать, о том, как мы, разработчики, можем создавать вещи, которые помогут им добиться большего успеха.
В настоящее время происходит небольшое поливание грязью, и я считаю, что единственный способ действительно исправить это - это игнорировать поливание грязью и сосредоточиться на проблеме. И проблема в настоящее время в том, что обслуживание, устранение неполадок и развертывание сайта ОЧЕНЬ трудоемко.
Спасибо Рихан
Напишите код, который проверяет работоспособность любой полученной конфигурации и сообщает о проблемах как непосредственно лицу, выполняющему настройку, так и в журналах.
Проведите четкое разделение между значениями конфигурации, зависящими от среды, и теми, которые должны передаваться в неизменном виде на улицу Dev, Test, Acceptance, Prod (DTAP).
Используйте программное обеспечение для управления версиями (например, Subversion), чтобы отслеживать изменения конфигурации во всех ваших средах.
Управляйте конфигурацией вашей среды DTAP, как страдающий манией величия.
Сразу после выпуска релиза и перед тем, как вы снова начнете кодировать, сделайте так, чтобы производственная среда была скопирована поверх всех других сред, включая среду разработки. Когда вы сообщаете об этом своим коллегам-разработчикам, посмотрите, кто из них станет белым, и спросите их, какие ресурсы они не могут заменить по желанию из системы контроля версий.
Самое главное !!! Вы, наверное, читаете это, думая, кто этот идиот? Это невозможно! Мы не могли этого сделать. Совершенно верно - конечно, не можете - не сейчас. (Если бы у вас уже не было проблем, вы бы не задавали вопрос). Так что отделите видение от реализации. Поделитесь этим видением с другими заинтересованными сторонами. Вместе решите, какими возможностями вы должны обладать, и составьте план, который поможет вам их достичь. Каждый цикл, релиз или что-то еще, убедитесь, что вы приближаетесь еще на один шаг к видению. Ставьте перед собой реалистичные цели и достигайте их. (Конечно, вы можете изменить свое видение, основываясь на опыте по мере продвижения.)
Я бы сказал, что помимо сохранения одинаковых настроек сервера и файлов конфигурации, у вас должны быть тестовые среды для развертывания в вашем офисе. Если ваши разработчики проверит, что разработанный ими код работает в среде, очень похожей на живую, они почувствуют себя более уверенно. Больше уверенности означает, что они обязательно развиваются быстрее (это то, чему мы научились у наших SCRUM-команд), и гораздо меньше путаницы и ощущения потери контроля.
В общем, я говорю: просто дайте разработчикам много машин для игры и тестирования, и вы увидите положительные результаты.
Самый важный шаг - это простой способ сделать конфигурацию всех серверов в вашей инфраструктуре как можно более согласованной. Стандартная операционная среда (SOE), если вы:
Как только вы это сделаете, станет значительно больше возможностей для автоматического развертывания, тестирования и т. Д.
Если конфигурация IIS идентична на всех серверах, вы можете обновить файл конфигурации, который IIS использует на одном главном сервере, и запустить сценарий, чтобы отправить его на все веб-серверы, протестировать и перезагрузить IIS. Вы можете сделать то же самое для ваших реальных файлов веб-сайта.
Я предполагаю, что если бы у вас была возможность стандартизировать серверы, на которых вы собираетесь развертывать, вы бы уже сделали это, поэтому я пропущу это предложение. Что вам нужно сделать, так это создать сценарии / MSI-файлы и т. Д., Чтобы автоматизировать процесс развертывания для группы эксплуатации. Настройка займет некоторое время, но исключение ручного вмешательства команды Ops в процесс - единственный способ обеспечить его бесперебойную работу. Я вовсе не оскорбляю их интеллект. Проблема в том, что они не знают, как работает код. Они не знают, как будет выглядеть конфигурационный файл с неверным значением. Они зависят от того, знаете ли вы, что это им поможет, а также от того, почему автоматизация является ключом к решению вашей проблемы.
Я предлагаю установить виртуальные машины локально, имитирующие различные серверы, чтобы вы могли снова и снова тестировать, как будет работать установка. Если ваш ИТ-отдел похож на мой, получить новые серверы будет сложно, так как это связано с бюджетом, распределением ресурсов и т. Д. Виртуальные машины снимают большую часть головной боли, поскольку вам не нужно новое оборудование, а вклад от кого-либо будет минимальным поскольку вам нужно только знать, как настроены серверы, а затем вы, вероятно, сможете сделать все остальное самостоятельно. Виртуальные машины также позволяют быстро вернуть машину в исходное состояние и снова попробовать процесс установки.
В моей инфраструктуре есть промежуточная среда, называемая предварительным просмотром, куда данные попадают до того, как попадут в рабочую среду. Код приложения на промежуточном уровне точно такой же, как и производственный код, поэтому любые проблемы с данными проявятся там.
У нас также есть тестовая среда для нового кода, которая работает со старыми, заведомо исправными данными (которые мы можем исправить, когда это необходимо, чтобы проверить, как код дает сбой).
Вообще говоря, такая сегрегация позволяет нам иметь довольно прочную производственную среду, и мы не видим слишком много неожиданностей.
Должен заметить, что я не особо этим занимаюсь, так как я не программист. Я просто синхронизирую базы данных и обновляю файлы, когда меня просят ;-)
Прежде всего ПОСЛЕДОВАТЕЛЬНОСТЬ. Убедитесь, что все ваши серверы одинаковы. Все веб-серверы W2003 должны выглядеть так же, как и остальные. Все серверы БД, все серверы Linux. Я имею в виду тем же. Та же версия ОС, те же патчи, та же структура каталогов ... Все!
Во-вторых, постановка. У вас должен быть отдельный сервер каждого типа, который можно использовать для тестирования вашего развертывания. Здесь вы делаете все свои ошибки конфигурации. Затем вы скопируете свою систему с этих серверов развертывания в рабочую среду.
В-третьих, к вашим файлам конфигурации следует применить концепцию «разделения проблем». Если разные модули имеют разные элементы конфигурации, поместите их в свой собственный файл конфигурации. Если есть конфигурация для конкретной машины, переместите ИТ в собственный файл конфигурации. Таким образом, вы можете развернуть затронутые файлы конфигурации с сервера развертывания вместе с самими компонентами.
Одно слово: резервные копии
Убедитесь, что у них есть надежные, централизованные, избыточные и согласованные резервные копии.