人们常常向我问及,应该如何提高自己系统管理员团队的工作效率。我希望在本文中向大家展示自己为系统管理员所打造的一套测试,这套测试应该会简化对团队进行基本评价的实施流程。这对团队管理者、企业领导及团队成员都非常实用。这同样是一套对于求职者极有帮助的方法:千万别误上了贼船,通过这一系列问题事先考量好新雇主的业务水平。
    ——Tom Limoncelli,Google系统管理员[了解详细]
将所有请求保存在一套数据库中有助于团队内部对信息的共享。它增强了团队整体工作内容的透明度,用户可以随时查看哪位成员在处理哪项请求、处理状态如何以及何时能够结束。项目管理系统的引入能够防止由用户请求或是追踪请求处理情况所造成的干扰现象。
如果你正好是一位经理,感觉自己的团队在时间管理技巧方面有所欠缺,那么其中的失误很可能在于你没有引入或者强制执行以下策略:为用户的帮助请求提供其乐于接受的解决方案;对“紧急情况”详加界定;服务着眼点:谁、什么情况、发生在哪里。
要制定新的方针或者将管理工作的水准进一步提升,大家需要做到一切以数据为纲。举例来说,PC部署团队的工作章程可能是:为每位员工的日常工作提供一台配置高端且标准化的计算机设备,更新周期为三年(这也是业界普遍采用的经营成本预期)。那么细则指标则可以
你的团队需要维基的协助。在这个广阔的平台上,大家可以将所有的策略(即指导性方向)与流程(即具体实施办法)加以记录。归档工作一旦结束,团队中的任何成员都能够顺利解读并加以执行。归档的同时也意味着新员工培训体制已经逐渐成形。而当企业希望招聘贤才
优秀的软件型密码“保全”系统数不胜数,大家也都说把密码写在纸上锁好就足够了。但最大的问题在于必须经常核查安全机制。我们无法确定会不会有某位有反社会倾向的偏激同事将错误的密码保存进来。如果大家做事喜欢精益求精,那么旧密码一位负责人、新密码另一
当安装一台机器等同于一个API调用,我们就都是程序员了。程序员使用源码控制系统。需要存入资料库的重要信息:脚本、程序、配置文件、文档以及其它各类成果。如果大家不确定某些内容应不应该保存进来,那就存。抽点时间学学Git、Mercurial或者是Subversion吧
Bug跟踪系统与项目管理系统不同,如果大家只是偶尔需要应付一下bug问题(因为没准不需要编写太多代码),那么对项目管理系统略加修整就足够了。Bug跟踪系统比起项目管理系统来在工作流程上完全不同。项目管理系统可以看作我们与用户之间的交互工具,而bug跟踪
成熟的团队往往以下列流程消灭bug:安全性,稳定性,bug,性能,新功能。根据Mark Burgess的意见,最重要的原则之一是“先保稳定性、再抓新功能”。我们做出的某些变更用于添加新功能、而另一些则旨在保障稳定性。整套检测考量的优先次序应该是功能、稳定性、
故障发生之后,你会将各项细节记录下来以便日后查询、还是希望问题随着时间逐渐淡出人们的视野呢?坚持撰写故障信息报告有助于维护稳定的运行环境,每次故障发生后都应拿出至少一套可行的预防性措施。你的监控系统能及时检测出标志性异常,进而使管理者能够先
每项服务都应该建立独立的小站点,其中必须包含下列七类标签:概述,创建,部署,常见任务,呼叫范本,灾难恢复,服务等级协议。从DNS这样最基础的服务项目着手,努力培养我们的备档习惯,并逐渐增加备档工作量与自动化处理能力。为业务流程创建主体骨架,让
未受监控的服务不能称之为服务,充其量只能算作一款运行中的软件罢了。监控机制应该以操作文档中的服务等级协议为基础。如果你还没有自己专用的服务等级协议,那么最基本的“上下线”警示也可以先凑合用用。别忘了将这些内容上传到呼叫范本当中。
呼叫轮换计划文档标明了谁、何时将“携带呼叫机”(或者负责报警及通知紧急情况)。在复杂的情况下,将一天划分为三个八小时进行分配及管理则更有效率。“跟着太阳走”则常见于全球性团队,因为成员遍布世界各地,所以保证工作主要由当地时间处于白天的成员处
质量保证体系相对于其重要性,在开销方面可以说相当廉价。它们不需要像即时处理系统那样性能强劲,它们只要具备一定的内存、硬盘空间以及CPU运算资源即可工作。基本上,它只需要运行于一台大型物理主机上的某套虚拟机中即可。这套流程不是挺理想的吗?
二十世纪初叶,美国及英国的煤矿工人们在下井前会先将金丝雀放入,以检测矿中甲烷及一氧化碳等有毒气体的浓度。从一台设备入手(不妨以自己的台式机为起点)、接着推广到数台设备(同事们的计算机该出场了)、最后是大范围部署,整个过程中出现的任何故障都必
在配置管理工具出现之前,系统管理员必须对设备变更进行手动处理。如果有一百台设备要处理,就必须一台台手动完成。显然聪明的系统管理员不会把大好青春浪费在这种无聊的工作上。头脑激荡过后,自动化工具就这样在管理员们的手中诞生了。
通常情况下,我们会让自动化流程在预定的时间段内运转。举例来说,让数据库验证脚本在下班之后启动并在夜间完成工作。但对某些网站而言,这些脚本应该由单独的某位系统管理员负责。也就是说,管理员下班后这些自动流程也要相应停止。
计划任务每天都在派发耸人听闻的警示报告,而就在大家渐渐无视这些废话时,真正的隐患很可能就在眼皮底下被忽略了。那么原则是,只有在需要立即调动人马解决的时候,才发送页面或短信提示。如果是需要24小时内处理的,则创建项目待处理就行了。
系统管理员感恩日贺礼:新概念运维
  • 你的团队是否采用了ticket system?
  • 没有
  • 不清楚
  • 你的团队是否使用了cfengine、puppet之类的配置管理工具?
  • 没有
  • 不清楚
  • 你的团队是否定期进行灾难恢复演习?
  • 没有
  • 不清楚
 
验证码: (点击刷新验证码) 匿名发表
 

51CTO旗下网站

领先的IT技术网站 51CTO 中国首个CIO网站 CIOage 中国首家数字医疗网站 HC3i 51CTO学院