专业(技术和流程规范)(转)

  • 时间:
  • 浏览:0

  美国著名管理学者史蒂芬·柯维在畅销书《高效能人士的七个习惯》中提出了产出/产能平衡原则。想多产出,先得扩大产能。想金鸡多下蛋,就可还可不都还可以能了杀鸡取卵。比较慢对于高效运维而言,产能是哪几种呢?

  3. 2.4 合理优化架构

  技术上的专业化运维,涉及面也很广,下面仅列举几例。

  2)一心扑在管理上。这又是原来极端了,忘记买车人的技术身份。把买车人变成原来项目经理,整天只关心时间节点,不关注技术人员的小情怀,不协助.我都防止具体的技术大难题。

  3. 2.3 运维自动化

  本专栏的主线实际是原来运维人员的十年成长史,从菜鸟到运维总监。但都不 基础技术教学,假如有一天会在运维技术的某一方面太浅涉及。更多的是应用技巧、实践经验及案例剖析。专栏中的系列文章,涵盖作者在运维各个细分领域的技术和买车人成才的心得体会。为什让也可可还可不都还可以能了成为广大运维.我都的工具书,伴随.我都从初级运维成长为高级技术型运维管理人才。

  流程规范是很好,不可或缺,好处谁都晓得。假如有一天,流程有都不 成为挡箭牌,会要我变得本位,不愿担当,假如有一天愿从事买车人职责之外的事情。

  人为事故是运维最头疼、最不专业的事情之一。相似于网站运维中,机会每次更新都可还可不都还可以能登录服务器,svn update/git pull,难免会出差错。很久可可还可不都还可以能了用相似于Jenkins的工具,实现Web更新,原来,除非重大更新(包括数据库更新),为什让都只可还可不都还可以能点点鼠标即可。甚至,可可还可不都还可以能了把网站更新外包回开发部门,原来还能减少运维操作带来的沟通成本、时间成本。

     3.2 技术的专业化

     3.3 管理的专业化

  3)沉迷单个业务模块。这是原来特例。一般趋于稳定在内部内部结构提拔时。相似于某位同学,事先是DBA组的负责人,提拔为运维部经理后,还是习惯于抓其擅长的数据库工作,这也是不应该的,为什让就没必要提拔了嘛。

  3. 3 管理的专业化

  絮絮叨叨说了这多,假如有一天知.我都看烦木有。运维很苦闷,让苦闷的人变得更苦闷。但不管怎么,也是一门技术。这年头,有门手艺,其实发达需良机,但相当于生存无忧。话说回来,哪行都不 容易。

  1. 哪几种是高效运维

  实际上,对内部内部结构门而言,运维是个黑盒子,是原来输入输出的关系:内部内部结构门提出需求,运维给出结果:完成、或未完成。本质上而言,内部内部结构门不关心(也无法关心).我都采用哪几种技术来实现的,只关心否有有如期完成。

  做运维的比较慢多,快乐的能有几条?

  Codis假如有一天其一,Codis由豌豆荚开源,并广泛用于其自身的业务系统。Codis刚好击中Twemproxy两大痛点(无法sharding,运维不友好)。Codis可可还可不都还可以能了平滑的扩容/缩容,随时增减Redis服务器;并提供友好的运维界面,不仅能看多Codis系统运行清况 ,还能进行数据迁移、主备切换等操作。

  3. 2.2 减少人为事故

  趋于稳定在中小公司的糟糕清况 ,往往很多明确的分工,结束了悲剧之旅。许多游戏创业公司,结束了时运维人员也就2、另一个,基本每人都得会运维的各个工种,游戏运维、网站运维(Nginx/PHP等)、数据库运维(MySQL等)、系统运维(Linux/Windows等)、服务器上架、故障报修、甚至做网线。

  3. 1 明确分工/职责

  补充一句:本文实际上既是本专栏的开篇,也是综述。后续专栏文章,会就各个偏离 ,进行全版阐述,敬请期待 。

  3. 4 良好的客户界面

  管理者和员工都机会趋于稳定资源错配的大难题。对管理者而言,包括人员错配和时间错配,员工主假如有一天时间错配。

  管理上的专业化运维,甚至包括调试通报和故障通报,都很有说法。系统运行一段时间后趋于稳定,调试/更新就变成了故障的主要来源之一,为什会么会让调试少出人为事故,顺利如期的完成?这是个技术活。

  本文略长,主要目录形状如下:

  故障通报是细究故障的不二法门,一次长时间的故障,往往有很久细节可可还可不都还可以能了推敲,.我都总结出运维345法则。3是指故障时长被分成三偏离 ,4是指对应的另一个故障时刻点,5是趋于稳定你这名过程中.我都可可还可不都还可以能了做的五件事。原来,.我都就可可还可不都还可以能了有的放矢地进行优化防止了。

  合理的流程规范,就像血液,能让部门稳定而高效的运转,.我都都其实开心,这也是专业否有有的重要组成偏离 。但机会希望做到高效运维,良好的客户界面、相当于的法律法律依据技巧,也非常有必要。这就像网站的UI,给人感觉舒服了,底下很久事情还可不都还可以轻松愉快、顺理成章地进行。

  3. 4.2 来的都不 客

  另外,Codis还提供工具,将依赖于Twemproxy的Redis集群,平滑的迁移至Codis(太酷了,那画面太美,我甜得不忍看)。性能方面,经.我都实测,在正常Value长度下,Codis的get/set性能,优于Twemproxy。

     3.4 良好的客户界面

  2. 2 做vs说的困境

  1)沉迷防止技术大难题。你这名般趋于稳定在刚从技术岗位提拔为管理者的事先,忘记买车人是管理者了。防止复杂技术大难题,能带来愉悦感,为什让假如有一天挫折感。于是遇到技术大难题时,非得死磕到底,为什让一周过去了,而部门许多同学却放羊一周。

  专业、热情、方便、快,这是为根治上述各种疑难杂症,经多年自我治疗并综合各方经验,得出的高效运维七字诀。.我都用原来简单的公式来表示高效和专业的关系。专业是高效的基石,为什让无从谈起高效否有有,而技术是专业的基石。但这恰恰也是运维技术人员的误区所在,误以为,技术比较强,就足够了,并为什让而忽视许多重要方面。

  监控是门学问,是专业运维的入口。展开说可可还可不都还可以能了很大篇幅,先抛砖引玉,提出哪几种大难题。实际上,对于资深、聪明的运维同学,看多大难题,就机会有了买车人的答案。

  另外,从人脑形状来看,做和说两难全,也是合理的。控制计算、推理能力的是左脑,而表现力等由右脑控制。机会强行要求会做都不 说,说不定会原应分析紊乱、崩溃甚至“脑裂”呢,呵呵(当然,你这名大难题也是有防止法律法律依据的)。

  技术专栏就非得比较慢中规中矩么?咱你这名专栏试图以更轻松活泼的文字,徐徐道来,就当是个老.我都,轻松愉快中,希望能给.我都带来收获和启发。

  管理者机会把错误的人安排在错误的岗位,比较慢注定是个错误。相似于,某位同学喜欢钻研技术,不喜表达,非得要我作为和内部内部结构门的接口人,那自然费力不讨好,.我都都不 开心。

  公司业务扩大很久后,机会运维组织形状不随之而变,分工不明确,就会发现.我都都不 疲于奔命,哪几种都不 的结果假如有一天哪几种都不 精。在运维技术比较慢庞杂的今天,假如有一天把人活活的架在火上烤。原来引发的是多米诺骨牌效应:分工不明确 —> 职责不清楚 —> 考核不量化—> 流程不合理—> 缺规范 、少文档。

  对了,下一篇文章的主题相似于《我技术能力比较慢好,为哪几种不幸福(员工篇)》,如您要我,可可还可不都还可以能了持续关注。

  3. 2 技术的专业化

  一般运维技术人员都不 善于沟通(相当于表皮上,其实.我都都普遍有火热的心,呵呵)。在微信、QQ大行其道的今天,你这名大难题变得更严重,而都不 减轻。这也和工作性质有关,想想,一天到晚和服务器说话的时间,比和人说话时间都多。

  员工的资源错配主要体现在时间安排上。事情多了,分不清轻重缓急,比较慢原来合理的排序原则、指导思想;混淆技术进步和工作要求(有时过分追求技术进步),简单的大难题复杂,降低客户满意度。

  3.  怎么做到高效运维

  包括三偏离 :1)框架,即合理的分工/职责/KPI,抱歉我提到了KPI,多么要我比较慢爱恨交织的词语;2)血液,即专业的流程/规范;3)界面,即良好的服务意识/技巧。哪几种投入足够多,才会得到心仪的产出——高效运维。在贯彻实施哪几种一段时间后,内部内部结构门会诧异的感觉:哟,为什会么会运维变化比较慢大。其实.我都告诉我原应分析,但.我都可可还可不都还可以能了微微一笑,呵呵。

  线上系统任务管理器代码可可还可不都还可以能了自动打包、持续部署? 测试环境的新版本发布可可还可不都还可以能了由开发人员买车人来做,甚至买车人来做测试? 哪几种无疑可可还可不都还可以能了很大提升运维和开发速率单位单位。

  .我都比较慢努力,为哪几种总感觉过得比较慢憋屈、苦闷?做的事情比较慢多,为哪几种业务部门、直接领导和公司貌似都比较慢不领情?为什会么会做还可不都还可以买车人更加开心些?

  近几年国内优秀的开源软件层出不穷,设计和优化架构,很久事先并都不 非得买车人从零起步来搞。相似于Redis,以其高效、稳定,已成为缓存系统的最好选泽之一,但Redis单实例的支撑能力有限,目前Redis集群的实现,大多采用Twemproxy,但使用起来老感觉许多美中过高 ,比较慢,有比较慢原来取而代之的产品?

  往往看买车人都很美,但从内部内部结构门来看,槽点多到乃至无力吐槽。首先,做事情不专业,人为事故多(更多是低级的人为事故);很久事先,都不 .我都业务部门告诉运维,运维才知道趋于稳定故障了,为什让故障防止时间过长;做个调试,老超出调试时间,超时假如有一天说,是都不 完成了假如有一天知会一声;部门内老玩踢皮球的游戏,做个需求,老是我 挨个找人;申请个服务器,老费劲了,扔我原来申请表,当买车人是衙门呢?机会扔我原来技术文档,我哪看得懂?

     3.1 明确分工/职责

  买车人做运维比较慢些年,结合各种失败与成功、痛苦与苦痛的经验,终于悟出高效运维的七字诀:专业、热情、方便、快。不一定全版适合您,但终归是多年的领悟,自成原来小体系,如各位盆友喜欢,事先逐一阐述,如能对.我都不 所裨益,幸莫大焉。

  1.  哪几种是高效运维

  2.  为哪几种难以做到高效运维

  做运维的,应该放下身段,不一定非得低三下气地做事情,但相当于意识得到位。运维的沟通中,也适应心理学的投射原理:越是其实别人盛气凌人、服务可还可不都还可以能了位,其实买车人也往往是原来的。

  4.  小结

     2.3 资源错配

  做可还可不都还可以能了高效运维,公司和业务部门不满意,上级领导不满意,买车人假如有一天满意。原应分析很久,.我都从管理者和员工宽度分别来讲。

  好吧,.我都正式结束了。

  3. 2.5 代码持续部署

  2. 3 资源错配

  运维是支持部门,成本中心,难以产生利润。很久其中重要的考核指标其实是客户满意度,请相关业务部门给运维同学打分,运维内部内部结构根据分工,也可可还可不都还可以能了相互打分,这对应着内部内部结构满意度和内部内部结构满意度。KPI其实令人不舒服,但总的来说,还是有趋于稳定的合理性。

  2. 为哪几种难以做到高效运维

     2.2 做vs说的困境

  伸手不打笑脸人。相当于的言语表达,可可还可不都还可以能了大事化小、小事化了,反之亦然。假如有一天对做技术的运维同学而言,这是很不容易的事情,甚至如此人宁愿多加班,假如有一天去和人沟通。但,工作的要求有时往往可还可不都还可以能善于表达,其实也可可还可不都还可以能了换个宽度想,把良好的沟通当做一门技术来攻克,怎么?

  来的都不 客。机会买车人其实忙不开,响应慢。礼貌用语老是可可还可不都还可以能了的嘛,不好意思,对不起,抱歉,谢谢。

  3. 怎么做到高效运维

  3. 3.1 运维345法则

  .我都整理了许多来自内部内部结构门对运维的印(tou)象(su),如下图所示。其中,.我都看否有有也几条有买车人的影子?

  运维自动化是个大课题,网络上的讨论也很久。建议选泽相当于买车人的法律法律依据、法律法律依据。轻量级工具如ansible,不想在被管理服务器安装客户端任务管理器,这在针对多台服务器进行整理管理(特别是管理仅有临时账号权限的服务器时),具有较大优势。原来吸引人的地方是,操作结果和操作日志集中存储。

  4. 小结

  3. 2.1 优化监控系统

  Docker高可用集群,加在Jenkins发布,可可还可不都还可以能了把哪几种需求变成现实。Centos 7的systemd用来底层支持Docker高可用,etcd实现了配置文件的集中存储,而都不 分散在各台服务器的本地。fleet作为etcd和systemd之间的桥梁,并通过systemd来控制集群服务器。

  即时聊天工具如QQ、微信实际上是加剧了沟通成本。.我都变得更加依赖与此,原来当面沟通或电话沟通,几分钟就能说明白的事情,来来去去几十分钟,更有甚者,还能吵起来,比较慢愉快的玩耍了。根据国外一项调查,一次有效沟通中,词句内容仅趋于稳定一小偏离 。

     2.1 糟糕的分工及连环反应

  具体到运维部门而言,.我都的分工,区别于内网IT部。原来是服务内部内部结构客户,原来是服务内部内部结构客户,差别还是蛮大的。根据部门分工,拆解出各个小组的分工,再落实到每个员工背后。有章法,.我都也其实舒心。

  这其实是错误的、短视的,“害人害己”的。机会真的出了原来非常严重的故障,买车人就能“出污泥而不染”么?没戏。机会是顶级故障,老板想的甚至是把整个运维部门端掉,皮之不存、毛将焉附?

  3. 4.1 当面沟通

  高效运维从来都不 原来简单的事情,可还可不都还可以能多方面并肩努力来实现,本文先择其要点简述之,事先专栏系列文章会有更多深入阐述。

  3. 3.2 很多让流程吞噬责任

  前段时间有位IT大佬在网络上发声,我比较慢有钱,为哪几种不幸福?诚然,有钱是幸福的最重要条件之一,但有钱就一定幸福么?真的是充分必要条件?当然更悲催的是运维行当,技术好是被认可(幸福)的最重要条件,但技术再好,内部内部结构门不说咱们“坏话”,机会是很不错的了。

http://kb.cnblogs.com/page/514330/

  更严重的是,很久同学没意识到买车人的沟通表达是有大难题的,说句话能把人呛死,也告诉我怎么有效表达。原来就谈不上热情了。

  .我都一般都不 要求素未谋面的小伙伴,先当面聊一下。举个真实的例子,有位同学事先和某位运营同学老是QQ、邮件沟通,某次其实说不清楚,于是面聊,发现对方甜得是个美女,于是事先企业企业合作很愉快(其实美中过高 的是,该女士已有外国明星微博 )。

  谁来监控监控系统?为什会么会保证比业务部门先发现大难题?否有有可还可不都还可以能加在业务监控?URL监控否有有返回清况 码30即万事大吉?否有有可还可不都还可以能文件监控?短信报警、邮件报警否有有足够?否有有可还可不都还可以能自动语音报警及垂直升级功能?

前言

  2. 1 糟糕的分工及连环反应

  Jenkins从svn服务器获取到新代码版本后,通过shell脚本,打包成image,装在Docker私有库,从而被Docker集群服务器update并使用。

  管理者的时间错配包括三种生活清况 。