Назад | Перейти на главную страницу

Редактирование пароля клиента в действующей системе - насколько это серьезная ошибка?

Сегодня мне было поручено добавить некоторых пользователей в Active Directory. Я все это сделал, но мне нужно было добавить список из 20 пользователей. Из этого списка 5 уже добавленных пользователей.

Инструкции в списке в основном заключались в том, чтобы просто добавить пользователей, что я и сделал. Я не могу получить пароли существующих пользователей из AD, поэтому в целях тестирования я изменил эти пароли существующих учетных записей. К сожалению, эти учетные записи используются (не знаю, как часто).

Мой старший разработчик сказал, что хорошо учиться на ваших ошибках, о которых вы не знали (я совершил аналогичную ошибку всего несколько дней назад, но это было связано с вниманием к деталям и на 100% моя вина, но я все еще хорошо справляюсь со своей работой - Я на испытательном сроке - как всегда говорит мой старший разработчик).

Воздействия на клиента не было (пока?). Насколько это большая ошибка?

Спасибо

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

Если учетная запись используется процессом, проблема зависит от того, известен ли этот пароль и сколько мест может потребоваться изменить, если это не так.

Обычно, если у вас нет привычки делать ошибки, я сомневаюсь, что вам стоит беспокоиться. Очевидно, я не твой менеджер.

Если они физические пользователи, должен быть способ отследить этих пользователей до реальных людей. Будьте активны и сообщите им, что их пароль был изменен, и им нужно будет связаться со службой поддержки. Если вы молча сидите и «надеетесь, что никто не заметит», вас могут уволить, когда они проследят за проблемой до вас. Признайте, что произошло, и примите меры, чтобы исправить это. И если вы не тот, кто отвечает на звонок, убедитесь, что они тоже знают, что произошло, чтобы они могли быстро и надлежащим образом ответить на жалобы.

Дошло до дела, всего 5 пользователей. Это не похоже на то, что весь офис крупной корпорации будет наводнен телефонными звонками в службу поддержки. Предполагая, что для сброса пароля требуется 5 минут, мы смотрим на потерянные 25 минут. Люди совершают ошибки, и в мире таких ошибок 25 минут с очень четким решением - это неплохо.


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

В качестве побочного вопроса, если в списке было показано, что 5 пользователей уже добавлены, почему вы просто не добавили и не протестировали только остальных 15? Ответьте на этот вопрос, и вы сможете ответить на свой собственный вопрос о том, насколько серьезной была эта ошибка (или ее можно было избежать).

Вы будете знать когда ошибка действительно плохой. Телефоны будут отключены, кто ответит на звонок, неделю будет на вас недоброжелательно смотреть и т. Д.

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

Я предлагаю в будущем сосредоточиться на том, как смягчать (минимизировать влияние) ошибок, а не устранять ошибки. Ошибки совершают все, время от времени этого не избежать. Учитесь у них. Ожидайте их.

  1. Худший случай: вы делаете ошибку и пытаетесь ее скрыть. Иногда это сходит с рук, иногда это имеет неприятные последствия.
  2. Лучший случай: вы допустили ошибку, это в тестовой системе / среде, и никому нет причин беспокоиться, кроме вас (возможно, это означает, что вам нужно потратить 15 минут на воссоздание тестовой системы / среды). Черт возьми, вы можете назвать эти ошибки «экспериментами» или как-то еще.
  3. Разумный случай: вы допустили ошибку, вы немедленно позволяете любому, кто может помочь смягчить ее (босс, старший системный администратор, персонал службы поддержки, затронутые пользователи), знать и минимизировать фактическое влияние на бизнес
  4. Альтернативный разумный случай: вы допустили ошибку и у вас есть план возврата, который позволяет немедленно исправить (скопировать файл конфигурации, отредактировать его, сломать, вернуть оригинал)

Например, если служба поддержки знает, что пароль пользователей X, Y и Z мог быть случайно сброшен, когда пользователь Y звонит по поводу невозможности войти в систему, они могут немедленно помочь ему с правильным решением вместо того, чтобы тратить 5 минут. с ненужным устранением неполадок, потому что ошибка была скрыта.

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