在咱们构建了事物后,咱们会开端优化它。在这里做些调整,那里做些更新,并监控全部以保证其正常运转。在大多数情况下,这结尾会涉及到必定程度的主动化,而这正是工具箱脚本和开发发挥作用的当地。咱们编写一些代码来主动化手动使命,将其放入生产环节,并移动到下一个目标。
抱负情况下,咱们大概尽可以多地对代码进行过错查看,但许多时分,开发人员并不会进行真正的过错查看,这可以带来无穷的灾祸。
咱们看一个实在的比如。咱们有一个虚拟效劳器模版(用于进行主动效劳扩展),当web应用程序的负载增加时,该模版会用来增建web效劳器。这是简略的作业—咱们只需求可以按一个按钮(或许主动履行它)。
假定咱们现已部署了程序来调整负载均衡器,以及增加新的web效劳器,咱们真正要注重的是保证这些效劳器上的应用程序仓库的稳定性和正常运转。咱们编写了一些代码,并将其放入到init脚本,让每台web效劳器可以下载某些需求的变量要素,以便可以正常运转。这又是简略的作业。咱们可以主动化anrsync或许scp进程。咱们可以十分疾速方便地测验这个代码。
可是,假如咱们没有对该代码进行满足的过错查看,咱们可以会发现,在半年内,整个应用程序开端间歇性溃散。或许文件名更改了,或许效劳器被更换,或许某人更改了authorized_keys文件。这些都是看苏无害的变化,当这些web效劳器发动时,它们将无法访问它们需求的东西,从而无法正常运转。
在这种情况下大概会发生这样的作业:效劳器经过SNMP或许电子邮件显现过错,并不会翻开web效劳。这个疑问将会清楚明了,或许一些调试就可以处理。但是,假如效劳器持续翻开一切效劳,并加入到负载均衡组,它可以无法正常作业。
依据所遇到的实践疑问,这可以意味着新效劳器上的一切效劳都溃散了,可以让效劳、内容和应用程序监控结构无法检测到进犯。效劳器可以看起来没疑问,但实践并不是这样。
假如这种影响相对较小,可以愈加令人不安,这意味着经过该模版生成的新效劳器发动时,又会呈现过错报告,或许只会有小部分用户受影响,由于现已运转的效劳器没有相同的疑问。这些疑问很难发现。笔者更情愿看到这样的情况:发动十几台效劳器、发现一个过错、发送警报,然后损坏应用程序。与损坏的可以损坏数据库的疾速应用程序相比,容量较低而减缓运转的应用程序更可承受。
这个疑问的关键是,看似细小的主动化作业可以可以完美地作业很长的时刻,但结尾仍是会带来损坏。主动驾驭仪是巨大的创造,但咱们仍是期望由人来驾驭轿车,以保证作业的正常运转。对于简略的主动化使命,咱们大概尽可以多地进行过错查看,由于这和主动化本身相同重要。
主动化的确可以带来很大的满足感。咱们可以构建一个机敏的结构来简化一些作业,然后看着其运作。但就像乐高车相同,假如咱们不注重,它结尾将会受阻。最佳一开端就做好计划文章来源:http://www.create-china.com.cn
北京金恒智能系统工程技术有限责任公司 版权所有 Copyright 2007-2020 by Create-china.com.cn Inc. All rights reserved.
法律声明:未经许可,任何模仿本站模板、转载本站内容等行为者,本站保留追究其法律责任的权利!
电话:86+10-62104277/2248/4249 传真:86+10-62104193-819 京ICP备10010038号-2网站XML
智慧机房
在线体验