工作汇报架构.docVIP

工作汇报架构 架构师工作述职汇报架构师工作总结述职汇报模板 眼看着又一年结束，想想今年过的还真是快，上个画面还是去年年末各种处理故障的场景，一眨眼一年就过去了。既然过了一年，还是得留下些思考和展望，否则就有些太无趣了。 还是套用那个老的不能再老的梗吧，the good,the bad and the ugly。 The Good 今年职位从高级码农变成了看上去很忽悠人的”技术专家“，虽然按专家的头衔来说应该做一些更深入的研究工作，不过受限于身体状态一直不好，一认真的思考问题就会头昏脑涨，只好做了很多给团队打杂的工作，所以好的部分大多数不是我个人的贡献，而是团队的功劳。 今年最主要的成果，应该是跟团队一起在很多事情上兑现了之前一直念叨的“应该”。 应该从现在开始做重构，而不是“到时候” 从去年接手团队之后就一直在跟历史代码做斗争，在做了很久看似出工不出活的“代码review”、“重构”、“增加测试”、“删代码”之后终于有了回报：我们的代码质量可以让我们在其中正常工作，不再需要为了一个看似简单的功能而大动干戈的在“屎一样的一大坨代码”里纠结半天了。 我们试过很多办法提升代码质量，包括强制code review、专门抽出时间重构、周会上的代码评审等等。每一种都或多或少 的有一些效果，但最有效果的做法是引入自动化的代码风格检查工具，可以发现大部分代码细节问题，并且很容易量化，对于“质量”这种没有实感的东西，量化是能够让你持续投入很重要的一个方面。 而最终的收益不仅是开发效率的提升，更重要的是，一个不断进化的团队中的一员在看到烂代码时，感受到的是“如何解决这些问题”的挑战，而不是”这些代码再也不会好了“的无力感。 应该通过提升开发效率完成工作，而不是靠加班 有代码不断优化的基础，我们也很自然的把服务过渡到了微服务架构。微服务架构让我们能够更敏捷的工作，不再需要忍受单体架构带来的“一个巨大的黑盒”带来的不便，我们可以对性能做更细致的分析，对问题做更精确的定位，对技术选型也有更多自由。在此基础上建立起了持续部署系统终于把上线变成了一件日常工作，“等我5分钟，我review代码的时候发现个bug，上个线就去吃饭”。 我跟很多人谈起这个“5分钟上线”的时候，他们都觉着我是个不负责任的人，并且一遍又一遍的问我：“上线上出问题怎么办？” 问我这个问题的人一定是没有考虑过“复杂度”本身就是一个巨大的问题源，当代码足够简单、依赖足够清晰时，很多问题就自然的消失了。实际上，我们现在的上线次数从每周两次提高到了每天十几次之后，上线产生的问题已经几乎不存在了。 应该通过报警发现问题，而不是用户投诉 我去年用几天写了一个报警系统，团队又在此基础之上建立起了一套特别靠谱的报警服务，不再依靠“检查系统内部有没有问题”，而是站在用户的视角，依靠探测程序检查“用户在使用时是不是有问题”。 站在用户维度报警的好处是，只要有报警，那么就一定有问题。于是我们终于从每天轰炸式的报警短信中脱出身来，不再需要“按报警频率估计服务有没有问题”这种无用的工作，也不需要面对bo“怎么用户都投诉了你们还不知道”的尴尬问题。只要有报警，那么就需要处理；反过来，只要没报警，那么绝大部分用户使用也不会有问题，我可以放心的玩《守望先锋》而不用担心bo会突然来电话。 最终，有惊无险的，我们做到了服务全年无故障（虽然还有几天才过完今年，希望这不是一个flag……）。 应该通过技术解决性能问题，而不是堆机器 微博的访问量极大，做个方案动辄要支持百万并发、千亿数据，但奇葩的是公司又很穷总是买不起新服务器(-_-)，性能优化就变成了极其重要的工作。 我们今年做了不少应用的性能调优，把每个服务的性能指标都提升了几倍（还有几倍是留给明年的KPI的-_-）。性能调优是一件有挑战又有成就感的事情，而且比较有意思的地方是，无论程序员的水平是好是坏，总是有调优的空间。水平弱一些的同学 可以调优业务代码和基本参数；好一些的优化架构和第三方组件；牛逼的可以深入jvm和内核原理。调优经验多了，总会有种“无论怎么优化也到不了头”的感觉。 另外，我们今年基于云服务、容器技术、调度系统、混合云编排系统、容量评估系统和自身的微服务架构体系，实现了公司成本部门老是念叨的的“按需扩缩容”功能，我们的直播互动系统也成为了微博内部首个按流量自动扩缩容的服务，达到了“5分钟完成无人值守自动扩缩容”的状态。在这个系统的帮助下，支撑微博直播互动服务的常备机器只有几台而已，参加技术大会看到有人谈直播架构时，总是莫名的有一种优越感…… 应该做更多有挑战的事情，而不是一直重复自己的工作 今年我们承担了更多微博的业务，我们如今应该算是微博里少有的“后端服务一条龙”团队，一整年来我们都在整合和优化各种服务的架构和链路。从消息箱底层业务，到tcp连接服务，