在实时系统上编辑客户端密码 - 这是一个多么严重的错误?

在实时系统上编辑客户端密码 - 这是一个多么严重的错误?

今天,我被要求将一些用户添加到 Active Directory。我完成了所有这些工作,但是,我有一个包含 20 个用户的列表需要添加。在这个列表中,列出了已添加的 5 个用户。

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

我的高级开发人员说从你不应该知道的错误中吸取教训是可以的(几天前我确实犯过类似的错误,但那是由于对细节的关注,100%是我的错,但我的工作仍然做得很好 - 我在试用期 - 正如我的高级开发人员总是说的那样)。

尚未对客户产生影响(目前为止?)。这是一个多大的错误?

谢谢

答案1

如果账户是实体用户,问题就很小。他们必须联系支持人员才能重置密码。麻烦程度取决于此人的资历以及联系支持人员的麻烦程度;使用笔记本电脑的远程用户会比坐在可以更改密码的人旁边的人遇到更多麻烦。

如果该帐户被某个进程使用,那么问题就取决于该密码是否为人所知,以及如果不知道的话,有多少地方可能需要更改密码。

一般来说,除非你经常犯错,否则我认为你无需担心。显然我不是你的经理。

答案2

如果他们是实际用户,那么必须有办法将这些用户追溯到真实的人。积极主动地通知他们他们的密码已更改,他们需要联系支持人员。如果你默默地坐在那里“希望没人注意到”,那么当他们把问题追溯到你身上时,你很可能会遭到解雇。承认发生了什么并采取措施纠正它。如果你不是接电话的人,请确保他们也知道发生了什么,这样他们才能迅速而适当地回应投诉。

情况紧急,只有 5 个用户。大型公司的整个办公室不会用电话轰炸支持团队。假设重置密码需要 5 分钟,那么我们总共会浪费 25 分钟。人都会犯错,在这种错误频发的世界中,花 25 分钟找到一个非常明确的解决方案并不算太糟糕。


然而,正如 David Pashley 所说,如果它们被某个过程使用,并且不是物理的人们,希望密码是已知的并且可以重置。如果不行,这可能是一个症结所在。

顺便问一下,如果列表显示已经添加了 5 个用户,为什么不直接添加并测试其他 15 个用户呢?回答这个问题,你就可以回答你自己的问题:这个错误有多严重(或者这是否是一个可以避免的情况)。

答案3

你会知道当错误真的糟糕。电话会响个不停,接电话的人会连续一周给你白眼,等等……

听起来你已经对实际对用户的影响有了大致的了解(影响很小甚至没有)。你按照要求做了(“添加用户”),而没有主动检查是否存在这些用户。不过,我必须说:系统管理最重要的“技能”之一是“关注细节”;我宁愿雇用一个几乎没有我特定平台经验但非常关注细节的初级管理员,也不愿雇用一个没有经验但在该平台上有一定经验的初级管理员。

我建议,今后要集中精力于如何减轻(尽量减少)错误的影响,而不是消除错误。每个人都会犯错,你无法避免时不时地犯错。从中吸取教训。期待错误。

  1. 最坏情况:你犯了一个错误,并试图掩盖它。有时你会侥幸逃脱,有时却事与愿违。
  2. 最佳情况:您犯了一个错误,这是在测试系统/环境中发生的,除了您之外没有人会关心(可能意味着您必须花 15 分钟重新创建测试系统/环境)。哎呀,您甚至可以将这些错误称为“实验”或其他东西。
  3. 合理案例:你犯了一个错误,你立即让任何可以帮助缓解的人(老板、高级系统管理员、帮助台员工、受影响的用户)知道并尽量减少对业务的实际影响
  4. 替代合理案例:你犯了一个错误,并且有一个可以立即修复的恢复计划(复制配置文件,编辑它,破坏它,将原始文件放回原处)

例如,如果服务台知道用户 X、Y 和 Z 可能意外重置了密码,那么当用户 Y 打电话说无法登录系统时,他们可以立即帮助他们找到正确的解决方案,而不是因为错误被掩盖而浪费 5 分钟进行不必要的故障排除。

答案4

在我看来,这听起来像是糟糕的指示(至少,你讲述故事的方式是这样的……)为什么给你一个有重复的列表?如果这是常规流程的一部分(例如,每周添加一次新用户),那么你需要调查生成列表的流程,以防止下一个初级员工犯同样的错误。

相关内容