В своей работе я периодически сталкиваюсь с ситуацией, при которой разработчики (а также тестировщики и другие члены рабочих групп) не имеют доступа к рабочим системам, которые предназначены для работы конечных пользователей.
Обычно они не имеют доступа как к данным, размещенным в этих системах, так и к различным сервисам и настройкам.
Обычно в этом случае они имеют доступ только к системам, предназначенным для разработки и тестирования.
Обновление, настройка и мониторинг рабочих систем в этом случае, как правило, выполняется администраторами.
Такой подход предназначен для того, чтобы защитить данные пользователей от несанкционированного доступа и в некоторых случаях имеет право на существование.
Однако, я считаю что в большинстве случаев такой подход приносит больше отрицательных моментов, чем положительных.
А именно:
Конечно, в ряде случаев, рабочие системы содержат данные, которые не желательны к распространению. Но все-равно, невозможно на все 100% закрыть доступ к этим данным. Кто-то (администраторы, служба поддержки) все равно смогут при желании получить к ним доступ. Так что здесь уже возникают вопросы доверия своей команде и юридического оформления неразглашения.
Да и в подавляющем большинстве случаев пользовательские данные не настолько конфиденциальны и интересны, чтобы их скрывать от разработчиков. Исключения, конечно, есть, но встречаются они не так часто.
Обычно они не имеют доступа как к данным, размещенным в этих системах, так и к различным сервисам и настройкам.
Обычно в этом случае они имеют доступ только к системам, предназначенным для разработки и тестирования.
Обновление, настройка и мониторинг рабочих систем в этом случае, как правило, выполняется администраторами.
Такой подход предназначен для того, чтобы защитить данные пользователей от несанкционированного доступа и в некоторых случаях имеет право на существование.
Однако, я считаю что в большинстве случаев такой подход приносит больше отрицательных моментов, чем положительных.
А именно:
- Часто у рабочей группы в этом случае нет возможности работать с тестовыми данными или действиями пользователей или средой идентичными рабочим. Причем, часто характер этих данных или действий может быть такой, что может быть довольно трудно осуществить генерацию таких тестовых данных, чтобы они по своему характеру могли соответствовать реальным. Это может приводить к разработке не самых оптимальных решений, созданных без учета реальной картины.
- У рабочей группы нет возможности осуществлять обнаружение и устранение проблем еще до момента их появления. Мониторинг работы систем, выполняемый администраторами, как правило работает уже по факту появления проблем, а не для их предотвращения заранее. Особенно это касается вопросов производительности, оптимизации и тому подобных вещей.
- У рабочей группы нет возможности корректировать действия пользователей, анализируя ту ситуацию с данными, которая у них сложилась. Особенно это касается систем с большим объемом пользовательских данных.
- Такой подходит снижает скорость и качество устранения проблем. Информация о проблемах, передаваемых от администраторов или службы поддержки, часто бывает неполной или искаженной и не дает возможности проанализировать и устранить проблему. Это проводит к запросам дополнительной информации о проблеме и т.д.
В результате время работы над проблемой увеличивается.
Конечно, в ряде случаев, рабочие системы содержат данные, которые не желательны к распространению. Но все-равно, невозможно на все 100% закрыть доступ к этим данным. Кто-то (администраторы, служба поддержки) все равно смогут при желании получить к ним доступ. Так что здесь уже возникают вопросы доверия своей команде и юридического оформления неразглашения.
Да и в подавляющем большинстве случаев пользовательские данные не настолько конфиденциальны и интересны, чтобы их скрывать от разработчиков. Исключения, конечно, есть, но встречаются они не так часто.
Rules:
ОтветитьУдалить1. В продуктивной системе недолжно быть доступа к средствам разработки.
2. Система разработки и тестирования должны быть идентичны продуктивной.
3. Со стороны заказчика должна быть выделена группа ключевых пользователей для проведения тестирования в тестовой системе, написания ТЗ и принятия работ.
Набор правил из международной практики и если им следовать то будет счастье
Ром, если речь идет о SAP и 1С, то я с тобой согласен.
ОтветитьУдалитьНо в большинстве случаев при разработке сложных высоконагруженных систем это не получается.
сложных высоконагруженных..... сложных? в чем сложность? в "высоконагруженности"? :) а можно пример?
ОтветитьУдалитьА ситуация по теме засада конечно, фсб чтоль какое окучиваете? ;)
Да ну, какое ФСБ...
ОтветитьУдалитьВзять хотя бы системы анализа любого трафика (интернет, телефония, автомобильный). Объем данных очень большой.
И кроме объема есть еще характер распределения данных по объему, который тоже имеет очень важное значение.
И создать в этом случает тестовую среду, идентичную реальной, очень сложно.
Понятно. Ну тогда на конкретных примерах объяснять, что гонщик готовившийся на жжжигулях врядли выйграет формулу-1. Подписывать соответсвующие бумаги, назначать соответствующих людей и т.п. Кстати ты упомянул 1С... В плане несанкционированного доступа, у этой конторы серьёзные санкции по этому поводу - проколовшимся, на карьере можно ставить крест - только если картриджи запрявлять, или сайтики рисовать в дальнейшем.
ОтветитьУдалить