管人还是管事 管事要较真 管人要大度 笔者多年前发表在播客文库上的一篇文章,现在拿出来分享给粉友们阅读。编者按:我们各级行政主管就是一个小老板,你要自己反思一下。老板对内实际上就是管人。而管人的根本在于管自己,你把道家、儒家看一看,完全就是这个意思。而管事则完全不同。管人要大度,管事要较真。管事就是给别人把规矩定好,然后认认真真、斤斤计较地去跟他算;管人是要员工认同你,首先你自己要的确做得很优秀,而且不能太较真,所谓宰相肚里能...
管理就是要以心交心,谨记目标 一篇来自播客文库的管理心得,值得粉友们学习。识别管理:帮助下属成功,发挥其长处温和儒雅是陈军给人的一贯印象,但在管理方面她有自己的一套方法。2000年陈军走上质量部管理岗位的时候,面临着从一个开发人员成为管理者的转身。要带领一支比自己资历深、技术强的专家队伍,她的法宝是谦逊、尊重与帮助提高。“如果你以谦逊的姿态去尊重和关心他们,他们也会给你最大的认可和回馈。管理不一定要采取强势和压制,...
大规模服务设计部署经验谈(9) | 结语 9 结语要降低大规模互联网服务的运营成本并改善服务的可靠性,一切从编写服务时注重运营友好开始。在这篇论文中,我们为“运营友好”做了诠释,并根据从事大规模服务的工程师的经验,总结了服务设计、开发、部署和运营的最佳实践。 作者简介James Hamilton,是微软LivePlatform Service团队的架构师,在微软有11 年工作经验,此前他曾带...
大规模服务设计部署经验谈(8) | 优雅降级和许可控制 8 优雅降级和许可控制当发生DoS攻击或者由于用户使用模式变化而带来的负载激增时,服务器需要能实现优雅降级和管理控制。例如,911恐怖袭击发生后,大多数的新闻服务都发生瘫痪,无法向所有用户群体提供任何可用的服务。与此相比,如果能够将一部分文章可靠地提供给用户,总比什么都不能提供好。最佳实践有两种:“大红开关(big red switch)”和许可控制,如果能够针对服...
大规模服务设计部署经验谈(7) | 审核、监控和预警 7 审核、监控和预警运营团队不能在部署环境中装配服务。要在部署过程中付出实质性的努力,以确保系统中的每个组件都可以生成性能数据、健康数据和吞吐量数据等。在任何有配置变更发生的时候,都必须在审核日志中记录详细变更内容、变更人和变更时间。在生产环境出现异常时,第一个要回答的问题就是最近到底进行过哪些变更。离开了审核跟踪,那么这个答案就是“什么都没被改过”,而且情况往...
大规模服务设计部署经验谈(6) | 运营和功能计划 6 运营和功能计划要高效地运营服务,关键在于让构建的系统有效地消除运营团队的绝大部分管理交互。这样做的目标,是让一个高度可靠的24 x 7 小时运行的服务,由一个8 x 5小时工作的运营团队就足以维护起来。不过世事难料,一组或者多组系统救火不成,无法恢复上线的事情是时有发生的。在熟知这些可能性的情况下,实现把损坏的系统标为当机这个过程的自动化。依赖运营团队手动更...
大规模服务设计部署经验谈(5) | 发布周期及测试 5 发布周期及测试在生产环境中进行测试是一件很现实的事情,必须成为所有Internet 级服务所必须的质量保证方式之一。在尽可能(可以掏得起钱)的情况下,绝大多数服务都应当有至少一个与生产环境相似的测试实验室,并且所有优秀的工程师团队应当使用生产级的负载,以反映现实的方式测试服务器。不过,我们的经验是,这些测试实验室即便模拟得再好,也绝不可能百分之百的逼真;它们至少...
大规模服务设计部署经验谈(4) | 依赖管理 4 依赖管理在大规模服务中,依赖管理这个话题通常得不到应有的关注。一般的准则是,对于小型组件和服务的依赖关系,对于判断管理它们的复杂性来说,并不足以节约成本。在以下情况中,依赖关系存在重要意义:1. 被依赖的组件在大小和复杂度上有重要价值;2. 被依赖的服务在作为单一的中央实例时存在价值。第一类的例子有存储和一致性算法(consensus algorit...
大规模服务设计部署经验谈(3) | 自动管理和预置 3 自动管理和预置许多服务编写的目的是为了在故障时向运营部门发出警报,以得到人工干预完成恢复。这种模式凸显出在24 x 7 小时运营人员上的开支问题;更重要的是,如果运营工程师被要求在充满压力的情况下做出艰难的决定,那么有20%的可能他们会犯错误。这种模式的代价高昂,容易引入错误,而且还会降低服务的整体可靠性。然而,注重自动化的设计会引入明显的服务模型约束。比如说,...
大规模服务设计部署经验谈(2) | 整体服务设计(2.7-2.10) 2.7 对吞吐量和延迟进行分析。应当对核心服务的用户交互进行吞吐量和延迟的分析,从而了解它们的影响。结合其他运营操作,比如定期数据库维护、运营配置(加入新用户,用户迁移)和服务调试等,进行吞吐量和延迟的分析。这样做对于捕捉由周期性管理任务所带动的问题是颇有裨益的。对于每个服务,都应当形成一个度量标准,用于性能规划,比如每个系统的每秒用户访问数,每个系统的并发在线人数...
大规模服务设计部署经验谈(2) | 整体服务设计(2.6) 2.6 设计运营友好的服务的实践设计运营友好的服务更具体的最佳实践包括:2.6.1 快速服务健康测试。这是构建验证测试的服务版本。这是一个嗅探型测试,可以快速在开发者的系统上运行,以保证服务不会以独立方式出错。要保证所有的边界条件都被测试到,是不可能的,但如果快速健康测试通过的话,那么代码就可以检入了。2.6.2 ...
大规模服务设计部署经验谈(2) | 整体服务设计(2.1-2.5) 2 整体服务设计一直以来,人们都相信80%的运营问题源于设计和开发,因此本节关于整体服务设计的内容篇幅最长,也最重要。系统出故障时,人们很自然倾向于首先去审视运营工作,因为这是问题实际产生的地方。不过,绝大多数运营问题都可以归因于设计和开发,或者最适合在设计和开发中解决。随后的内容凸显一个共识,即在服务领域,将开发、测试和运营严格分离不是最有效的方式。在环顾众多服务...
大规模服务设计部署经验谈(1) | 引言 本文中提出的最佳实践,来自于作者多年大规模服务设计和部署的经验,为设计、开发对运营友好的服务提供了一系列良好的解决方案。■文/James Hamilton 译/赖翥翔1 引言本文就设计和开发运营友好的服务的话题进行总结,得出一系列最佳实践。设计和部署大规模服务是一个高速发展的领域,因而随着时间的流逝,任何最佳实践集合都可能成熟并完善。我们的目的是为了帮助人们...
企业级负载均衡源码全套转让 10年研发,5年商用成果,耗资研发成本1000多万元,完整的企业级负载均衡产品源码和文档全套转让!该产品和F5 负载均衡,深信服负载均衡的功能完全相同,性能优于深信服负载均衡,应用客户数量达1000多家!由于业务转型,现一口价40万转让该产品完整的全套源码和所有开发文档,用户文档,安装文档!交易方式:预付70%,交易完成后付30%该企业级负载均衡产品源码质量和文档质量以公司名义担保!请放心...
mysql重启,表中自增的重新从1开始问题 mysql重启 表中自增的重新从1开始问题http://blog.sina.com.cn/s/blog_6c3748830100ygxl.htmlhttp://www.iteye.com/problems/15429
如何分析最耗CPU的线程 最耗CPU的进程可以通过pidstat命令分析,但线程如何分析呢?以下通过寻找最耗CPU的java线程为例来说明,希望能抛砖引玉。 举例:找到最耗CPU的java线程ps命令命令:ps -mp pid -o THREAD,tid,time 或者 ps -Lfp pid结果展示: 这个命令的作用,主要是可以获取到对应一个进程下的线程的一些信息。 比如你想分析一下一个j