在现场系统上编辑客户密码 – 这是多么糟糕的错误?

我的任务是今天将一些用户添加到Active Directory中。 我做了所有这些,但是,我有一个20个用户的列表添加。 在这个列表中,列出了5个已经添加的用户。

列表的说明基本上只是添加用户,所以我做了。 我无法从AD获取现有用户的密码,因此出于testing目的,我更改了现有帐户的这些密码。 不幸的是,这些帐户正在使用(不知道多久)。

我的高级开发人员说,从你不知道的错误中学习是很好的(我在前几天做了一个类似的错误,但是这是由于注意细节,100%是我的错,但是在我的工作中,我正在缓刑 – 正如我的高级开发总是说)。

有没有客户的影响(还?)。 这个错误有多大?

谢谢

如果账户是实体用户,那就没有什么问题了。 他们必须联系支持才能重设密码。 麻烦取决于这个人是多么高级,他们接触支持涉及多less麻烦。 使用笔记本电脑的远程用户将比坐在可以更改密码的人旁边的人更麻烦。

如果帐户被某个进程使用,麻烦取决于该密码是否已知,如果不是,可能需要更改多less个地方。

一般来说,除非你有犯错的模式,否则我怀疑你不用担心。 显然我不是你的经理。

如果他们是物理用户,那么必须有办法将这些用户追溯到真实的人。 积极主动地通知他们他们的密码已被更改,他们将需要联系支持。 如果你静静地坐在那里“希望没有人注意到”,那么当你把问题追溯到你的时候,你很可能会被解雇。 确认发生了什么,并采取措施进行纠正。 如果你不是那个打电话的人,确保他们知道发生了什么事情,所以他们可以迅速适当地回应投诉。

推动来推,只有5个用户。 这不像一个大公司的整个办公室将通过电话洪水支持。 假设重置密码需要5分钟,我们总共在25分钟内丢失了某个地方。 人类犯了错误,在这样的错误世界里,25分钟的解决scheme也不错。


然而,正如David Pashley所说,如果他们被一个stream程所使用,而不是身体上的 ,那么希望密码是已知的,并且可以退后。 否则,这可能是一个棘手的问题。

作为一个侧面的问题,如果列表显示已经添加了5个用户,为什么不只是添加和testing其他15个? 回答这个问题,你可以回答你自己的错误是多么糟糕的问题(或者甚至是一个可以避免的情况)。

你会知道什么时候一个错误是非常糟糕的。 手机会响个不停,接电话的人会给你一周的脏兮兮的,等等。

听起来你已经有一个体面的想法是什么对你的用户的实际影响是(最小到没有)。 你做了你所说的(“添加用户”),而不主动首先检查这些用户是否存在。 但是我必须说,系统pipe理最重要的“技能”之一就是“注意细节”。 我宁愿雇用一个初级pipe理员,几乎没有任何经验,在我的特定平台上,他们对于细节的关注比没有它的平台上的初级pipe理员更有经验。

我build议将来要专注于如何减less(最大限度地减less)错误的影响,而不是消除错误。 每个人都犯错误,你不能避免它发生。 向他们学习。 期待他们。

  1. 最坏的情况:你犯了一个错误,并试图掩盖它。 有时你会摆脱它,有时会惹火。
  2. 最好的情况:你犯了一个错误,它是在一个testing系统/环境中,没有人有理由关心,除了你(也许意味着你必须花费15分钟重新创buildtesting系统/ env)。 哎呀,你甚至可以把这些错误称为“实验”。
  3. 合理的案例:你犯了一个错误,你立即让任何能够帮助缓解(老板,高级系统pipe理员,帮助台工作人员,受影响的用户)的人知道并最小化对业务的实际影响
  4. 替代合理的情况:你犯了一个错误,并有退出计划,允许立即修复(复制configuration文件,编辑它,打破它,把原来的回)

例如,如果服务台知道用户X,Y和Z可能意外地重置了密码,当用户Y呼叫不能login系统时,他们可以立即帮助他们正确的解决scheme,而不是浪费5分钟不必要的排除故障,因为错误被掩盖了。

听起来像对我不好的指示(至less,你已经讲述了这个故事的方式…)为什么你给与重复列表? 如果这是常规stream程的一部分(比如每周添加一次新用户),那么您需要调查产生该stream程的stream程,以防止下一位小辈犯同样的错误。