兼职管理1、响应时间 微信响应时间 超过5分钟 2次 中止合作2、培养能力 经验、工具3、收益高于预期4、工程师和质量关于裁员裁员名单是根据个人在公司工作期间对代码的贡献来制定和排名的。高效工作总结：0、必胜信心1、结果导向2、完成时间3、物理专注公司管理思路：互相投资、互相信任，非传统主雇关系1、培养人，把能力传授给下面的人2、放权3、分享机制小团队项目组基本管理：1、放手，新问题主动处理、老问题交给下属处理，借此制定标准处理问题流程化；2、榜样，有困难主动承担、有问题主动冲锋；3、让功让利，向上让功、向下让利；温和派领导人管理思路：1、立功，对公司有贡献；2、握权，能够影响员工收入组成40%、考核评分、项目奖金；3、守信，不轻易承诺、一旦承诺必须兑现；4、立标杆，培养典型员工进步并树立标杆；团队凝聚力1、身先士卒，带动员工积极性；2、知人善任，用人长处；3、勇于背锅；4、尊重、感谢，公约机制；提高员工工作效率1、责任到人；2、限定时间；3、确定标准；4、重复一次；5、检查机制；6、验收考核；老版轻松X成就感V想明白，布置下去1、会算账，不算公司赚多少钱、算员工能赚多少钱；2、会画饼，公司壮大时候做到位置、发展前景；3、会激发，你是专家我不行、顶梁柱；
软件架构师应该知道的97件事之概括
架构师是一种神秘的职位，据说每个架构师都有密不可传的方法，当然我们不信，更多的是只可意会不可言传。就是说了我们也不会懂，因为还每到“火候”。所能做的就是，当我们到这种火候的时候我们能想起来曾经有过架构师这么说过，然后我们就可以更自信的向前大步走....1、客户需求重于个人简历要想拥有漂亮的个人简历：我们常常向客户推荐技术、手段，甚至方法论来解决问题，使用时髦的编程技巧和流行的范式，有时候根本不是寻求解决问题的最佳方案。积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你才是最好的履历。2、简化根本复杂性，消除偶发复杂性根本复杂性指的是与生俱来的、无法避免的困难。比如，协调全国的空中交通就是一个“天生的”复杂问题，必须实时跟踪每架飞机的位置。偶发复杂性：是人们解决根本复杂性的过程中衍生的。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。怎么做？尽量选择源自实际项目的框架，警惕那些象牙塔里面的产品。3、关键问题可能不是出在技术上简单的项目也会翻船，而且这不是个别情况。大多数项目是人完成的，人才是项目成败与否的基础。如果团队里有人工作方式不正确，拖项目后腿怎么办？有一种非常古老但很完善的技术可以帮助你解决问题。它可能是人类历史上最重要的技术创新，这就是对话。有几个简单的对话技巧可以显著改善对话效果：不要把对话当成对抗。不要带着情绪与人沟通。尝试通过沟通设置共同的目标。4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格沟通必须简明清晰，没有人愿意阅读冗长的架构决策文档，架构师言简意赅的表达观点是项目成功的必要条件。架构师往往忽略了自己也是领导者。作为领导者我们必须获得同伴的尊敬才能顺利开展工作。所有的成员都希望有明确的沟通和开明的领导。只能这样才能改善沟通效果，建立团结健康的工作环境。5、架构决定性能大家似乎理解，事实并未如此，有些架构师认为简单的更换底层架构就足以解决应用的性能问题，他们很可能轻信了“经测试产品性能超出竞争对手25%”，比如从4ms到3ms，这1ms放在一个性能极低的架构里几乎可以忽略不计。归根结底，所有产品和架构必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，通过物理连接和逻辑协议实现的通信必然有延时。因此，应该承认架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单的通过更换软件，或者“调优”底层软件架构来改善的，我们必须在架构的设计和重新设计上投入更多的精力。6、分析客户需求背后的意义顾客和最终用户通常提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径，当了解顾客的需求背后的意义，我们可以为顾客解决真正的问题并可能降低难度。7、起立发言许多架构师都是从技术岗位上成长起来的，他们擅长和机器打交道，然而架构师更需要与人打交道，无论劝说开发人员接受具体的设计模式，还是向管理层解释购买中间件的利弊，沟通都是达成目标的核心技能。有经验的架构师会很重视推销自己的想法也明白有效沟通的重要性，其中一个简单又实用的技巧是在2人以上的场合发表意见时请“站起来”，起立发言非常重要尤其是当其他人坐着的时候。当你站起来的时候无形中添加一种权威和自信，自然就控制住了场面，听众不会随意打断你的发言，这些都会让你的发言效果大为改观，你会发现站立可以更好的用双手和肢体语言。在10人以上的场合，起立发言方便你与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的作用不可小觑。起立发言还可以让你更好的控制语气、语调、语速和嗓门，让你的声音传的更远。当你讲到重点内容时，注意放慢语速。发声技巧也能显著改善沟通效果。比沟通事半功倍，起立发言是最简单、有效的方法。8、故障终究会发生硬件会出错，于是我们增加冗余资源来提升系统的可靠性，同时也增加了至少有一台设备出错的概率。软件会出错，增加额外的监控程序也会出错。于是我们又为自动化增加监控，结果是更多的软件，导致更高的故障率。类似的如：三里岛核电站泄漏事故既然必然会出错就需要事先设计好防范故障的模型，以应对威胁系统安全的意外情况。9、我们常常忽略自己在谈判我们都面临过削减预算的要求，如果资金运转促襟见肘，技术方案只能委屈求全。比如如下情景：“我们真的需要这东西吗？”项目投资人发难道。尽管真的需要，我们通常也不能这么回答，因为此时我们是在谈判，此时我们需要认清自己的角色，不能把自己当成工程师，而且投资人明白他在和你谈判，我们应该这样回答"真的需要吗"这类问题：“单台服务器每天至少崩溃3次，没有第二台我们甚至无法跟董事会演示，事实上我们需要4台服务器，构成2组，这样在需要时断开一组而不必被迫关闭系统。即使有一台出现意外，也不影响系统正常运行”10、量化需求速度快不能算作需求，响应灵敏和可扩展也不能算需求，因为我们无法客观地判断是否满足了这样的条件。正确的描述需求应该像这样：“必须在1500ms内响应用户的输入。在正常负载下，平均响应时间控制在750ms-1250ms之间。由于用户无法识别500ms以内的响应，所以我们没必要将响应时间降到这个范围一下。”11、一行代码比500行架构说明更有价值架构说明书（specifications）很重要，因为它描述了构建系统的模式，但是静下心来全面彻底地理解架构——即从宏观上把握组件之间的交互，又着眼于组件内部的代码细节——也很重要。架构师往往容易被抽象的架构所吸引，沉迷于设计过程。事实上仅有架构说明书是远远不够的。软件项目的最终目标是建立生产体系，架构师必须时刻关注这个目标，牢记设计只是达到目标的手段，而不是目标。如果亲自开发，应该珍视自己花在写代码上的时间，千万别听信这会分散架构师精力的说法。这样既能拓展你的宏观视野，也能丰富你的微观世界。12、放之四海皆准的解决方案架构师应该坚持培养和训练“情景意识”——因为我们遇到的问题千差万别，不存在放之四海皆准的解决方案。“情景模式”：调查有经验的架构师处理复杂问题的方式。有经验的架构师和设计师的答案如出一辙：只须使用常识....【一个】比“常识”更贴切的说法是“情景意识”——在给定情景下对合理性的把握。架构师通过学习和实践，不断积累的案例和经验，建立足够的情景意识。他们通常需要十年的磨练，才能解决系统层次的问题。13、提前关注性能问题商业用户的需求主要表现卫队功能的要求。系统的非功能特性则由架构师负责，包括：性能表现、灵活性、持续正常工作时间、技术支持资源等。但是对非功能特性的初始测试往往被拖到开发周期的最后阶段，有时还由开发团队来操刀，这样的错误屡见不鲜。在项目周期的最后阶段才关注性能问题，会导致我们错失大量历史信息，这些信息包含性能变化的细节。如果性能是架构设计的重要指标，就应该尽早展开性能测试。在采用敏捷方法开发的项目中，如果有2周为一个迭代周期，我认为性能测试的开始时间最迟不能晚于第三次迭代。坚持技术测试是需要耐心和毅力的，无论是搭建合适的测试环境，采集适当的数据集，还是编写必要的测试用例，都需要投入大量的时间。14、架构设计要平衡兼顾多方需求平衡兼顾各方的要求和项目的技术需求CEO需要控制成本运营部门要求软件易于管理二次开发人员要求软件代码容易学习方便维护业务部门：旅行合同义务、创造收益、树立客户口碑、控制成本，创造有价值的技术资产技术部门：确保软件的功能15、草率提交任务是不负责任的行为傍晚时候，团队正在完成本次迭代的收尾工作，一切按部就班、有条不紊。只有约翰赶着赴约有些急躁，他仓促写完自己的代码，编译、检入，然后匆匆离开。几分钟后红灯亮起（许多采用敏捷开发方法的软件公司（例如ThouthtWorks）在每个团队成员的桌上放置一盏3色灯，用来表示当前的集成状态，黄色正在集成，绿色集成成功，红色集成失败），构建失败。约翰没来得及执行自动测试就草率地提交了任务，连累大家无法继续工作。正常的工作秩序全被打乱了。这个时候架构师就该发挥作用了，营造一种团队文化，以维护流程通畅为重，以浪费他人时间为耻。要做到这一点，务必在系统内实现完善的自动测试功能，纠正开发人员的行为。沉下心来改变系统的生产效率，缩短流程避免各行其是，才能缩短开发时间。总之一定要杜绝一切草率提交任务的念头。16、不要在一棵树上吊死负责构建系统的人似乎无法接受这样的事实：没有哪种数据类型、消息格式、消息传送机制，甚至主流的架构组件、策略、观点用来能够用来解决所有的业务问题，毕竟当大家都希望摆脱业务需求不断滋生的意外和烦恼。才用多钟表现方式、多钟传输方式不是为了消遣。应当认识到，通过分解系统的非功能参数，可以为客户提供多样化的解决方案。17、业务目标至上在商业化的背景下开发企业应用，架构师必须成为业务部门和技术部门沟通的桥梁，周旋调解，兼顾双方利益，同时业务目标来驱动项目 开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。在启动一个软件项目之前，应当制定计划，明确投资回报的预期。架构师必须把握这个预期，并预估该项目的商业价值，避免做出错误的技术决策，造成经费超支。用业务目标驱动项目开发，才能保证软件开发团队的长远利益。18、先确保解决方案简单可用，再考虑通用性和复用性许多用来实现基础设施的代码，包括组建、框架、类库、基础服务，普遍存在一个问题，它们设计一向强调通用性而不考虑具体应用。如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。虽然很多架构师重视通用性，但这样做是有前提条件的。并非所有人都需要通用性，愿意为它掏钱。19、架构师应该亲力亲为称职的架构师应该通过示范领导团队，架构师通常都取得过不错的业绩，有份出彩的简历，容易获得业务人员和技术人员的青睐。但除非他能展示自己的实践能力，否则很难赢得团队的尊重，团队成员将无法从他身上学到东西，大家甚至难以在他的领导下做好本职工作。20、持续集成架构师（无论是应用架构师还是企业架构师）都应该在项目中鼓励推广持续集成的方法和工具。现在持续集成已经取代了“尽早构建，经常构建”（build early and often）的提法，它确保当前的开发不会出现意外，是一种降低风险的技巧。构建应用程序是持续集成最主要的内容，它通常是自动执行的，可以设置在夜里执行，或者当源代码改变时自动触发。当然你也可以选择手动构建。21、避免进度调整失误导致项目失败的原因很多，最常见的是中途临时调整进度。改变计划回答带来以下问题：仓促的进度会导致拙略的设计、蹩脚的文档，可能引发质量问题，导致用户拒绝签收仓促完成代码导致bug增多，测试不充分增加测试中可能出现的问题以上问题均能引发产品质量问题，而解决产品质量的问题代价更高。最后的结果是成本不降反升，通常项目就是这样失败的。22、取舍的艺术架构师应该明白鱼和熊掌不可兼得的道理。如果2个性能本身就是冲突的，满足一项就会导致另一项失败或者整体失败。23、打造数据库堡垒创建牢固的数据模型要从第一天开始牢固的数据模型既可以保障当前的数据的安全，又为今后提供可扩展性。要保障数据安全就必须隔离来自应用层的bug（在不断变化的应用层中这些bug无处不在，不会因为你的勤奋而消失），必须严格遵守引用完整性规则，尽量使用域约束规则，还要选择恰当的键，即保证数据的完整性，又遵守约束规则。要实现可扩展性，就必须正确地将数据标准化。以便今后在数据模型上添加架构层：千万不要偷懒走捷径。为了妥善保护数据库必须拒绝无效数据，阻止无意义的关系。在定义键、外键、域约束时，应该采取简洁的容易被理解和验证的名称，使他们含义不言自明。数据模型中的域规则也要做到物理化和持久化，避免他们在应用逻辑发生改变时被删除。为了充分发挥关系型数据库的作用——让它真正的成为应用的一部分，而不仅仅是存放数据的库房——必须从开始构建数据库时，就深刻理解业务需求。随着产品的演变，数据层也会发生变化。24、重视不确定性当你面临2中选择的时候应该仔细考虑设计中的不确定性。迫于压力，人们常常为了决策而决策。这时可以借鉴期权思想（指在期货交易中，权利的受让可以在将来的某个约定的时间，根据当时的情况决定是否行使权利，即推迟做决定时间），当你在不同的系统开发路线之间举棋不定时，不要急于做出决策。推迟决策，直到掌握更详实的信息，以便做出更可靠的决策。但也别太迟，要赶在这些信息失效前利用他们。25、不要轻易放过不起眼的问题问题出现时，虽然个别团队成员会发现一些端倪，但往往由于大多数人认识不到其严重性，这些问题不是被忽略就是被搁置，知道变得难以解决。注意造成的原因和哪些方法克服这些消极因素。26、让大家学会复用有这样一种观点，认为设计优良的框架、细致考虑并精巧实现的架构自然会被人们重复利用。但也是在满足下列条件下擦可能被复用：大家都知道它的存在大家知道如何使用它们大家认识到利用已有资源好过自己动手27、架构里面没有大写“I"英文单词架构（architecture）里面有字母”i"但不是大写的“I”。它代表的不是那个喜欢唤起别人关注，喜欢凌驾于众人之上的“I"(自我）。自我可能是我们这最大的敌人。如何避免犯错误？需求不会撒谎。重视团队合作。检查你的工作。自我反省。28、使用”一千英尺高“的视图用来了解正在开发的软件质量如何在架构图中，系统是由若干个小方框组成的，方框之间的连线代表着各种含义：依赖关系、数据流、共享资源等。这种图好比从飞机上俯瞰地面上的风景，我们称之为“三万英尺高”的视图。另一种典型的视图是源代码，好比占在地面上看大地。两种视图都无法冲分钟展现软件的质量：前者太抽象，而后者细节太多，以至于我们看不清整个架构。很显然我们需要一个介于2着之间的视图——“一千英尺高”的视图。"一千英尺高“的视图提供的信息来自恰当的层次，囊括大量数据和多钟度量标准，例如方法数，类扇出数和圈复杂度。具体的视图与特定的质量属性密切相关。一旦我们绘制出合适的视图，判断软件质量就更客观了。29、先尝试后决策创建一个应用需要作出很多决策。有些决策设计挑选框架和函数，而另一些则需要选定特定的设计模式。架构师应该持续关注那些马上要制定的决策，架构师可以在决策之前，要求几个开发人员商量解决方案，比较不同解决方案的优点和弊端。对同一个问题尝试2种或者2种以上的解决方案，可能是代价最低的选择。事后发现方案不合适或者是没人发现方案不合适都是糟糕的情况。30、掌握业务领域知识高水平的软件架构师不仅要懂技术，还要掌握问题空间对应的业务领域的知识。缺乏业务领域知识的架构师不能顺利地解决问题，无法把握业务目标和业务需求，也就难以设计有效的架构来满足需求。31、程序设计师一种设计程序设计属于设计范畴而不是生产范畴。软件的生产则是自动化的，由编译器、构建工具和测试代码共同完成。如果把编写代码看成设计行为，而不是生产行为，我们就能采用一些已经被证明有效的管理方式。这些方法过去用于管理不可预测性的创新工作，比如研发新车、新药、新的电脑游戏。我们指的是敏捷的产品管理方法和精益生产方法，比如SCRUM。32、让开发人员自己做主多数架构师都是从开发人员干起的。以前作为开发人员你很少有机会仔细观察整个系统是怎样组合在一起的，而作为架构师这是你工作的重点。如果想出色的完成工作，是不可能有空闲去干预开发人员的。33、时间改变一切选择值得投入精力的工作简单原则，回顾以前或者更早的项目时，几乎都会惊诧自己当初的做法，如果有机会再做一次，我们一定会以更简单点的方法来完成。这就是时间的作用。别跟以前的工作过不去，你现在看重的设计思路，可能2-3年后就会被自己否定。34、设立软件架构专业为时尚早设计软件架构师一门手艺，从业者无意要通过实践和训练才能在这个领域获得成功。35、控制项目规模估算与准确的科学计算相差甚远，所以产品特性实现起来常常比预期要困难。缩小和控制项目规模策略：抓住真正需求。分而治之，设置优先级，尽快交付。敏捷方法的倡导者提倡开发”最简单有用的东西“，越复杂的架构越难以实现。缩小项目规模通常会降低架构的复杂性，这是架构师提高成功几率最有效的途径。36、架构师不是演员，是管家架构师接受新项目，都渴望证明自己的价值，这是人之常情。炫耀和作秀与指挥开发项目背道而驰。架构师的职责和管家类似，承担着管理他人资产的责任。架构师要满足不同领域的客户需求，而这些领域的专业知识通常是架构师所不具备的。37、软件架构的道德责任软件世界的道德范畴边界并不清晰，尽管有些行为无疑是不道德的，比如侵犯他人的公民权利等，但还有些行为的道德意义不被察觉，比如浪费别人的时间。架构师的每项决策（例如设置必填项和规定流程），都限制了用户可以做什么不能做什么。这比法律容易的多，并且还找不到法院受理他们的诉讼。我们可以从倍增效应的角度来看待软件的影响。软件问题所造成的损失将以成不可估量的倍数出现，尤其是给人心理上的。假设架构师要实现一个新功能，简单的设计要1天完成复杂的设计要1周的时间，但简单的设计要强迫用户输入大量的数据，这个过程常常会丢失数据，耽搁工作，让人非常沮丧。从长远看浪费别人的时间将远远超过你省下的时间。损人利己是不道德的行为哪怕程度很轻。38、摩天大厦不可伸缩土木工程不只是设计建筑这么简单，真正的难题在于规划整个施工过程，确保建筑物拔地而起，包括从奠基到竣工的所有工作。其中有很多经验值得我们借鉴，尤其是对于部署大型集成化软件系统（包括所有企业应用和web应用）。如果把软件比喻成土木工程，那么传统的大爆炸式软件部署方式就好比把备齐的建筑材料一股脑仍上天，指望他们瞬间拼成一座大厦一样那么可笑。相反，无论是开发新项目，还是替换已有的系统，都应该逐个部署系统组件。2个优点：首先，隐藏在代码中的技术风险是部署软件时无法回避的问题，其次这种方法迫使我们设计清晰的组件间接口。有些是不能借鉴的，尤其是在建筑工程中屡试不爽的”瀑布式“施工方法。毕竟摩天大厦不需要可伸缩性。应用软件只要具备了用户要求的功能便可发布，不用等到十全十美。事实上，产品越早发布公司的净收益就越高。这样既可增加商业利润又可以改变架构品质，这样实用的技巧实在不多。39、混合开发的时代已经来临混合编程：在一套软件系统中同时采用多种核心编程语言现在可以采用基于文本协议（text-based protocols）了。这些新技术以特定格式的文本作为载体，便于所有人编写和理解，为混合开发提供了前所未有的可能性。架构师把若干个强大的开发工具组合起来使用，以往的标准是挑选合适的编程语言，现在则演变成挑选合适的编程范式。选择多了并不总是好事，但至少好过以往软件架构非此即彼的窘境。40、性能至上性能指标和其他指标一样重要。有些设计师把性能放到最后考虑。我们通常把系统响应用户输入的时间作为衡量性能的标准。生产率通常用来描述构架系统的效率，也属于性能范畴，其重要性在于直接影响项目的成本和进度。系统的人机交互性能直接关系到用户是否愿意掏钱。包括：响应时间，是否直观，操作步骤是否简单。合格的说明书除了注明系统每秒钟的响应次数，还要测量典型的任务时间。非交互性组件的性能同样影响着系统的表现。在考虑系统的实现方法和运维策略时，架构师和设计师应该密切的关注系统的性能表现。41、留意架构图里面的空白区域软件系统由相互依赖的程序组成，我们把装配这些程序的方法及程序之间的关系成为架构。假设某个箭头表示”使用HTTP协议，发送SOAP-XML格式的同步请求/响应消息“，由于架构图里面的空间有限，写不了这么多内容，所以通常用简单的注释表示。从技术角度出发可以简写成”XML over HTTP",如果从业务角度出发，有可能写成“查询库存单元”。不同的程序看似通过箭头直接联系，其实不然，矩形之间的空白区域充满 着各种软件和硬件。应该理解每个箭头包含的静态信息和动态信息。42、学习软件专业的行话每个专业都有行话，同行之间讲行话方便交流，清晰、简洁、高效的方式与同行进行沟通，是软件架构师应具备的能力。架构师必须掌握基本的架构模式和设计模式，学会辨别不同模式，并借助他们和同行及开发人员进行交流。架构和设计模式可以分为四大类：企业架构模式、应用架构模式、集成模式、设计模式。企业架构模式定义架构的全局框架结构。应用架构模式指出了全局架构下的子系统及局部应用的设计方法。设计模式研究架构中各个组件的构造方法。除以上4种外，架构师还应该了解和提防各种反模式。反模式：影响软件开发中的常见错误：需求分析麻痹症、委员会设计、蘑菇管理、死亡征途。43、具体情境决定一切”分享设计架构的理念让我觉得很滑稽，因为我认为压根就不存在设计理念““毕竟，没有理念本身也是一种理念”最重要的设计经验是具体情境决定一切，根据它设计尽量简单的解决方案。换句话说，架构决策只有在情境需要时，才能牺牲尽量简单的原则。脱离了具体的应用场景，孤立地比较技术的优劣是毫无意义的事。44、侏儒、精灵、巫师和国王架构师好比国王，应该熟悉各种人的性格特点，招聘不同性格的人加入自己的团队。安排任务时应该时刻考虑所有开发人员的性格特点。为不同性格的团队成员安排合适的任务，如果大家有机会磨合、相互适应，就能轻松化解决各种难题。45、向建筑师学习建筑师名言建筑师社会性的表演，是上演人类历史的剧院。要想成为伟大的建筑师，优雅丰富的心灵远比聪明才智重要。建筑师自诩上帝的助手，甚至觊觎上帝的宝座。（上帝：客户）天底下没有完美的建筑。建筑师首先应该是伟大的雕塑家，或者伟大的画家，否则他不过是个建筑工人。46、避免重复你的开发人员在重复无需思考的工作吗？代码里面反复出现某些相似的片段？某些代码是复制粘贴后稍加修改而成的，如果出现这些情况，说明团队工作效率不高。软件开发的真理：复制时魔鬼重复性的工作拖累开发的进度。消灭重复的内容是你的责任，为此，应该重新研究框架，创造更完善的抽象机制，请专门制作工具的程序员（toolsmith）帮你完成切面框架（aspect framework），使用代码生成器。要想消灭重复内容必须有人采取行动。47、欢迎来到现实世界工程师偏爱精确，整天和0和1打交道的工程师更是如此。现实世界不是二进制的。顾客有可能撤销确认过的订单，支票有可能跳票，信件可能丢失，付款时间可能延迟，许下承诺还可能失信。这些已经够糟了，可分布式系统又带来了新的不一致性。服务有可能失效，状态有可能在毫无征兆的情况下改变，事务处理可能得不到保证。分布式系统不但是松耦合、异步、并发的，而且不遵守传统的事物语义。48、仔细观察别试图控制一切妄想掌控一切的架构师只能设计出紧耦合的、脆弱的解决方案，这一套已经行不通了。我们必须启动必要的辅助机制。我们已经进入分布式、松耦合系统的时代。构建松耦合的系统多少有些麻烦，我们希望系统足够灵活，别因为一点点小的改动就支离破碎。随着系统的配置越来越灵活，当前的系统配置包含了更多的信息，为了便于理解，必须从中提取模型。比如，搞清楚哪个组件负责向逻辑信道发送消息，哪个组件负责接收消息，就应该把组件间的通信关系用图标模型记录下来。与模型驱动架构不同，你先构建出灵活的架构，然后从实际的系统状态中提取模型。49、架构师好比两面神罗马神话里面，两面神是司守门户和万物始末之神。他有两张面孔，凝视2个不同的方向。两面神兼顾前后，过去与未来。架构师在不同的对象之间架起桥梁，比如梦想和现实、过去的成功和未来的方向、业务目标与开发i限制。我们应该以两面神为榜样，工作上严格把关，综合考虑新情况与老经验，在成熟技术上不断创新，既满足当前的业务需求，又兼顾未来的额发展规划。50、架构师当聚焦于边界和接口“哪些应该在一起，哪些应该分开”51、助力开发团队架构师可以施加约束，也有机会成为推动者。要确保开发人员拥有他们所需的工具。要确保开发人员拥有所需的技能，确保他们能够获得必须的培训。同时，也要尽可能的参与到开发人员的选拔中。只要不违背软件设计的总体目标就让开发人员自己做决策。最后，保护开发人员，不要让他们卷入到不那么重要的工作中。52、记录决策理由在软件开发社区，对于文档尤其是关于软件自身设计的文档的价值，争论颇多。分歧一般集中于两处，一处是“详细的前期设计”的有效价值，另一处则是使设计文档化和不断变化的代码库保持同步的难易程度。记录软件架构决策理由的文档，长期有用，无需为之付出过多维护精力，具有很高的投资回报价值。根据项目的不同灵活选择合适的文档格式来记录架构决策的方方面面，格式可以是文本、维基、或博客形式的速记备忘录，也可以使用较正式的模板。比如这些文档：可以作为和开发人员沟通的工具，说明应遵循的重要架构原则当开发人员对架构背后的逻辑提出质疑时，使团队能够就事论事向经理和利益相关者说明这样构建软件的确切原因把项目移交给下任架构师好处是：它逼着你说出理由时，有助于确保基础是扎实稳固的、如果相关条件发生变化，需要对决策重新评估，它可以作为一个起点53、挑战假设，尤其是你自己的延迟判决法则：“臆断是事情搞砸的根源”软件架构师的最佳实践表明，应该记录下每个决策背后的理由，当这一决策包含权衡（性能vs.可维护性，成本vs.上市时间等）时尤须如此。有些小道消息：开源软件不可靠位图索引带来的麻烦比好处多....确保这些假设清楚明确，对后继者和未来的重新评估来说非常重要。更重要的是拿出证据。不要忽略相关这个词语。事实和假设是构建软件的两大支柱。务必确保软件的基石坚实可靠。54、分享知识经验从所有的失败的经验中，我们可以学到很多东西。在像软件开发这般年轻的行业中。为了持续发展传播经验和知识至关重要。每个团队在自己的小世界小角落里所学到的东西，可能会在全球产生影响力。55、模式病人们记录和发现模式，避免后来人重新发明车轮。对于软件架构师而言，设计模式是极有价值的可用工具之一。使用模式，能够创造更易沟通更易理解的通用解决方案。模式与良好设计息息相关，如果发现自己试图把最喜欢的模式硬套在不适用的问题空间上，那么你也许是”模式病“患者。不要让一展模式功底的欲望遮掩了务实真知。56、不要滥用架构隐喻架构师喜欢使用隐喻（metaphor）。对那些通常比较抽象、复杂和变化的移动的目标，隐喻提供了良好的具体媒介。找到实物作为正要构建的东西的隐喻，会更容易沟通和讨论架构全局。滥用架构隐喻经常会出现问题，让架构师不知所措，比如：业务领域的客户开始越来越喜欢系统隐喻，这时，系统还在构想中，在这种情况下所有各方共享的是最乐观的可能解读，但其中并没有包括任何必要的约束。开发团队认为隐喻比实际业务更重要。由于团队耽溺于隐喻，你不得不开始修正那些古怪的决策。所交付的系统包含了许多遗留名称，从早已老旧过时，有待重新鉴定隐喻，到多次重构和重复挖掘的概念。57、关注应用程序的支持和维护应用程序的支持和维护永远不是事后才考虑的事情。由于应用程序80%的声明周期都在维护上。开发人员和支持人员拥有的技能不同，就像开发/测试环境和生产环境有截然不同的目的一样。系统管理员会遇到的问题：*系统管理员不能重新提交请求消息来重现问题。*一旦投入使用，就没有调试器可以用了。....就会出现以下症状：*大多数问题都需要开发人员参与。*支持团队讨厌新的应用程序。....为了确保应用程序脱离开发人员之手后能成功运行，应该做到：*理解开发人员和支持人员确实具有不同的技能*在项目中尽早的引入支持负责人。...当系统管理员很开心的时候大家都会很开的。58、有舍才有得有时，接受某种约束或放弃某个特性，可带来更好的架构，这种架构在构建和运维上都会更加简单，而且成本更低，往往能产生富有创造性和创新性的结果。59、先考虑原则、公理和类比，再考虑个人意见和口味如果是单凭个人经验、意见和口味创建的架构是没有考虑原则、公理、和类比所带来的好处的。这样做，架构文档化会更容易，从描述架构所遵循的原则开始即可。原则清晰的架构能够把架构师解放出来，使其免于全面复审而忙得不可开交。原则和公理确保了架构的一致性。60、从“可行走骨架”开始开发应用为了实现、验证和不断发展应用架构，一个非常有用的策略，便是从Alistair Cockburn所谓的“可行走骨架”开始。“可行走骨架”是对系统的最简单实现（a minimal implementation),它贯穿头尾，将所有的主要构件组件连接起来。从可工作的最小系统开始训练全部的通信路径，可以带来“正朝着正确的方向前进”的信心。对于大型系统通常是由多名开发人员共同构成，对于大型系统而言更多的协调工作是必不可少的。从“可行走骨架“开始，保持系统一直运行可用，递增式地进行培育，使其逐步增长。61、数据是核心软件开发人员最初将软件理解为命令、函数和算法构成的系统。如果稍稍后退站远一点，计算机只不过是能访问与操作一堆数据的时髦工具。代码在计算机中运行时，底层数据的状态不断发生变化。举例而言，如果想了解Unix操作系统，通过源码逐行挖掘是不大可能奏效的，但是如果你读过一本unix内部数据结构的书，便可更好的了解unix底层是如何运行的。从概念上开看，数据比代码更加精炼，也更好理解。即使对于最复杂的系统，通过这种面向数据的视角，即通过底层信息的结构整体开看待系统，也可以将之缩减为细节的有形集合。然后降低其复杂性。数据在大多数问题中处于核心地位，业务领域问题由数据蔓延到代码中。诚然，软件架构中的许多问题确实和数据相关。从设计角度来看，大多数系统的关键问题，就是要在正确的时间从系统获取正确的数据。62、确保简单的问题有简单的解软件架构师解决了许多非常困难的问题，但也会解决一些相对容易的问题，对于简单的问题，不要使用复杂的解决方案。为复杂问题付出的直接成本可能看上去很小，但是其潜在成本要大得多。为问题的解决方案付出的代价不仅仅只是在实现和维护上。架构师会从主观的判断或潜在不确定性需求出发，产生调整解决方案的强烈冲动。但记住一点：试图猜测未来的需求时，错的概率是50%，错的非常离谱的概率是49%。63、架构师首先是开发人员不管解决方案多么优秀，决定实现能否成功的最重要因素之一是让开发人员愿意接下任务。虽然不是工作的一部分，架构师还是会经常去处理一些比较复杂的任务。这样做的目的有两个：第一，这是一种乐趣，而且还能帮我们做到宝刀不老；第二，这有助于向开发人员表明，我不是碰到麻烦时会干吹烟卷却束手无策的架构师。64、根据投资回报率进行决策（ROI）我们对项目所做的每一个决策——无论是技术、过程，还是与人相关——都可以看做一种投资形式。回报率（rate of return），也成投资回报率（Return On Investment,ROI)，是衡量投资是否成功的标准之一。将架构决策视为投资，并将相关的回报率也一并考虑在内。在判断每个决策选项是否务实或恰当时，这种方法很有用。65、一切软件系统都是遗留系统即使系统十分前沿，采用了最新的技术开发而成，但对接手它的下一个人而言，它也会是遗留系统（legacy）。必须面对这种情况！在今天，软件很快便会过时，这已经成为软件的天然属性。如果软件能够存活下来哪怕只有数月的时间，都必须承认一点：负责维护工作的开发人员肯定要对软件进行缺陷修复，这是不可避免的。这引出如下几个问题。*清晰性：各个组件和类的角色一定要清楚*可测行：系统易于验证吗？*正确性：结果和设计或期望的一致吗？*跟踪性：可容易修复紧急缺陷66、起码要有2个可选的解决方案对于某一个问题，如果只考虑了一个解决方案，那你就有麻烦了，在给定的约束条件下，寻找问题的最佳方案，期望第一个解决方案即满足全部的需求和约束，几乎是不可能的。这种问题即使有——也绝少是真地由于缺乏可选方案而造成的，它更可能是架构师缺乏特定问题域的经验所致。67、理解变化的影响好的架构师能够将复杂性降到最低程度，他在解决方案中给出的抽象，应该能够为更高的层次提供坚实基础，同时，还应该能足够务实地应付未来的变化。优秀的架构师能够深刻理解变化带来的影响，这种影响不仅限于彼此隔离的软件模块之间，而且包括人与人之间，以及系统与系统之间。变化有多种不同的表现形式：*功能需求的变化*可扩展性需求的变化*系统接口被修改。。。。幸运的是许多工具和技术可以用以减轻变化的影响：*进行小规模的增量渐变*构建可重复运行的测试用例*跟踪好依赖关系*降低复杂性*自动化重复任务68、你不能不了解硬件对于许多软件架构师，硬件容量规划问题是一个超出其舒适区的主题，但它的确是架构师工作的重要组成部分。如果没有硬件方面的专业知识，预估待开发系统的硬件配置是非常容易出错的。比起采购超出实际所需的硬件，为容量规划留出预算是更为经济的。69、现在走捷径，将来付利息长远看来，系统维护将比项目初期的开发消耗更多的资源。测试：使用测试先行的设计，进行单元测试碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也就越高。70、不要追求完美，足够好就行软件设计师，尤其是架构师，在评估针对某个问题的解决方案时，会倾向于考虑它是否优雅完美。有些瑕疵只须经由一些调整或迭代重构便可消除。建议：不要屈服于企图使设计或实现达到完美的诱惑！把目的设定在“足够好”就行，当已经达成目标时就停下来。71、小心“好主意”“好主意”会杀死项目。有时候杀伤力会很快见效，但更常见的症状是：因屡屡错过的里程碑和不断攀升的缺陷数量，项目苟延残喘，最终不治身亡。“好主意”：那种诱人2的、不用想都知道的、外表无辜、以为不可能会产生伤害的那种“好”注意。“好主意”真正的邪恶之处在于它的“好”。如果出现下列关键词，要小心了：*如果....会更酷。*“嘿，他们刚刚发布了YYY框架的XXX版本。我们应该马上升级”。72、内容为王我见过无数这样的设计，它们大都永无止境地强调需求、设计、开发、安全及可维护性，但从未关注系统的真正要点——数据。73、对商业方，架构师要避免愤世嫉俗雇主希望偶们能够解决问题，倾听和了解雇主的业务，是我们必须掌握的最为关键的技能。成为优秀架构师的秘诀之中有一个关键要素，那便是:要对工作满怀激情，但不要是那种带着愤怒和火气的“激情”。74、拉伸关键维度，发现设计中的不足应用程序的设计轮廓，最初是基于特定的业务需求、所选择的技术或现有的技术、性能要求、预期的数据量，以及构建、部署和运营上可用的财务资源。无论采用什么样的解决方案，都要求能满足或超越当前环境下的要求，成功运行起来，否则这就不称其为解决方案了。拉伸解决方案的关键维度，看看哪些方面会遭到破坏。75、架构师要以自己的编程能力为依托在架构上，架构师都期望能够创建出精巧的设计和完美的抽象，来优雅的解决手头的问题。如果能再项目中多安插些技术那就更让人有成就感了。但是最终要实现设计的不是架构师。如果开发人员需要去实现那些架构上的“杂技”，那将会对整个项目造成巨大影响为项目设计架构时，对实现的每个设计元素所需要的工作量，要做到心中有数；如果以前曾开发过其中某种设计元素，那么估算所需的工作量将会容易得多。不要在设计里面使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架，不要使用自己没有亲自配置过的服务器。76、命名要恰如其分如果都不知道一个东西应该叫什么，那你肯定不知道它究竟是什么。如果你不知道它究竟是什么，那么你肯定不能坐下来为它编写代码。77、稳定的问题才能产生高质量的解决方案最好的架构师不是要去解决难题，而是围绕难题开展工作。架构师要能够将四处弥漫的软件问题圈起来，并画出其中的各种边界，确保对问题由稳定的、完整的认识。这些问题应该具有以下特性：*内聚性：问题块在概念上市统一的，其中所有的任务、数据和特征都是相关的。*能够很好地和其他块分隔开：这些块在概念上进行了规范化处理；他们很少重叠或者根本不重叠。78、天道酬勤架构师常常被描述为一种注重创造力与问题解决能力的职业。除了创造力外架构师还应当具备另一项同样重要的特质——勤奋，勤奋指很多方面，但归根结底是指具备坚强的毅力，并且对系统的每项任务和每个架构的目标都能投入足够精力。勤奋经常和平凡携手同行。勤奋还意味着要求架构师必须真正做好那些看似简单的任务，坚守承诺。79、对决策负责由于软件架构师比组织中的其他人更有影响力，所以他们必须对自己做出的决策负责。研究表明有超过三分之二的软件项目要么彻底失败了，要么未能成功交付（项目延期、预算超支、客户不满意）。究其根本原因，有许多事由于架构师做出了不当的决策，或者无法最终执行正确的架构决策。如何做出有效的架构决策：首先,对决策的过程有充分认识第二，定期对架构决策进行复审第三，要贯彻架构决策最后，可以将一些决策委托给响应问题域的专家，不必出自其自身。80、弃聪明，求质朴智力超群、足智多谋对任何人来说都是值得称道的品质。对架构师来说，这些素质尤其被看重。然而，聪明也包含某些额外的隐含意义。它也暗指能快速想出脱身之计的能力，但这种本领最终要依靠一些小伎俩，骗局或掉包计。聪明的设计僵硬难改，其细节会对全局产生太多牵扯，往往会一触即毁。81、精心选择有效的技术，绝不轻易放弃作为软件设计开发的老手，每个架构师通常都有一些让自己屡屡取胜的武器用来武装自己。这些技术由于种种原因深受架构师青睐，排在其首选解决方案的前几位。这并不是说某种技术一旦入围就可以永久罔替。选择新技术虽然有风险，但其价值能为你带来质的飞跃。考虑技术未来的前景。软件架构师工作很大一部分，是要选择用以攻克难题的合适技术。82、客户的客户才是你的客户在软件会议需求会议上，要这样想象：你的客户并不是你的客户。实际上真的不难做到，因为，事实便是如此。如果你的客户的客户赢了，那么你也赢了。如果你在编写一个电子商务应用程序，那么应该考虑的应当是那些会在那个网站上购物的人的需求。如果你的客户有意无意的忽视他们的客户所看重的重要事项——那么请放弃这个项目。需求收集会议不是项目实现讨论会议。83、事物发展总会出人意料事物的发展总会出人意料。在设计时，人们很容易陷入误区，投入太多的时间在设计上。设计中的这些微小变化累积起来，很快就需要对设计进行一次较大的变更。设计是一个不断发现的过程。84、选择彼此间可协调工作的框架软件框架是系统的基础，在选择时，不仅要考虑每个框架自身的质量和特性，也要关注共同构成系统的各个框架之间是否能和谐相处。如果框架间有重叠，则要确保了解候选框架在逻辑域或关注层面上的重叠程度。为了尽量减少框架间互有重叠的概率，要根据系统需求的应用场合，选择精专强大的框架。系统应该由多个相互独立的框架构成，其中每个框架都精专于各自的领域，但同时又非常简洁、包容、灵活。85、着重强调项目的商业价值对于非软件业从业人员，软件架构显得虚无缥缈，架构项目在争取资金时会遭遇到困难。大众心理学表明，大部分人会相信亲眼所见的东西。而拥有预算决定权的人，几乎都是受商业价值驱使的。下列五部，会成功将架构提案打造成经典的商业项目：1、形成价值描述（提高 生产力，改进效率的能力）2、建立量化度量标准3、回过头来关联传统商业的衡量方式4、知道该在哪里停止5、寻找恰当的时机86、不仅仅只控制代码，也要控制数据源代码的控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容常常会根据源代码的变化而变化，他们也是这一过程的重要组成部分，因此也要对之进行类似的控制。数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内，做到一次性构建整个应用程序。数据迁移不应该作为一种补救措施。87、偿还技术债务对任何已投入实用的项目（也就是说，有客户在实用产品），无论是要修复缺陷，还是要添加新功能，总有必须修改产品的时候。在那点上，会面临2个可能选择：花合适时间“一次做对”，或者取巧走“捷径”，争取尽快推出修改过的产品。作为架构师必须决定怎么做才有意义。88、不要急于求解架构师多半是开发人员出身。开发人员的主要职责是解决编程问题。相比架构问题编程问题的范围更狭窄。很多编程问题是很小但比较棘手的算法问题。架构师和开发人员因此学会了迅速进入问题解决模式，但有时候没有解决方案才是最好的而解决方案。许多问题根本不需要解决，看似问题是因为我们只关注表面症状。学会审视问题本身。看看能否改变问题。我们必须戒除“问题解决迷恋症”。89、打造上手的系统我们十工具的制造者。我们制造的系统，一定要能够帮助人们——通常是其他人——做事，否则就是去了存在的意义，我们也将无法从中获取报酬。用户体验应该是“上手的"。90、找到并留住富有激情的问题解决者组建一支汇聚优秀开发人员的团队，是确保软件项目成功非常重要的事情之一。一旦建成便竭力维护。提放批评过度。批评过度，可能会扼杀开发人员的创造力，降低其生产力。更糟糕的是，可能会在团队内部造成纷争。以正确的方式经营开发团队，其重要性不言而喻。91、软件并非真实存在软件工程经常被拿去和完善的传统学科——如土木工程——进行对比。这些类比有个问题，和这些传统实践制造的有形产品不同，软件并非真实的存在。业务和软件都是活生生、会变化的实体。业务需求可能会因新近收购的业务伙伴和营销战略而迅速变化。业务需求很可能会发生变化，因为我们构建的产品是柔韧的。记住，需求文档不是蓝图，软件并非真实存在。我们创造的虚拟物比实体物更易于改变。92、学习新语言架构师必须让别人能理解你。业务人员专业用语和程序员专业用语是有差别的。架构师需要掌握各个沟通团队的语言。93、没有永不过时的解决方案今天的解决方案会成为明天的问题。今天做出的选择，在未来很大程度上是错误的。“分析瘫痪”是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜测对未来而言最好的技术。94、用户接受度问题人们并不总是满心欢喜地接受新系统或系统的重大升级。这种情势，可能会对项目的成功构成威胁。架构师的目标，是要去了解和衡量用户的接受度问题带来的威胁，并朝着能减轻这些威胁的方向开展工作。“项目拥戴者”可以帮助消除用户接受度问题。这个职位的最佳人选，是能代表用户或利益相关方的人。95、清汤的重要提示清汤是一种非常清澈的肉汤，上品清汤非常清澈，需要不断重复的精炼浓缩才能烹出。设计架构也应当不断精炼浓缩。软件中许多漏洞的需求和缺陷，可最终追溯到含糊笼统的语言描述上。拒绝模凌两可的废话。概念需要在加上“总是、永远、不管任何情况下”仍然成立。96、对最终用户而言，界面就是系统糟糕的用户界面埋没了太多的好产品，最终用户通过界面访问系统。架构师应该确保，随着架构变化而变的用户界面也要能够反应用户的期望。不仅要让最常用的交互易用，而且要使最终用户能够从中获得回报。97、优秀的软件不是构建出来的，而是培育出来的在一开始就要设计庞大的系统几乎毫无好处可言。设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。粗略的从后面的十几个里面提取出以下几个方面：数据：程序的核心就是数据，数据的结构表现出数据的形态，数据可能会随着架构更新，数据库也要更新。文档：文档是为了避免反复思考而存在的，类似于代码注释，文档是对工程的注释。尤其是对架构师的每一个有可能产生分歧的决策，必须用文档标明决策原因。推迟决定（也有其他翻译）：是软件开发模型的策略，这样有助于收集更多有关决定的信息。团队：团队需要的不是单一的一类人，但需要的一起能合理分配工作并完成工作的一类人。找到好的团队成员一定尽心维护。用户：客户至上，客户体验是架构师最好的简历，标志着软件的成功与否。沟通：和业务部门沟通，需要学习业务部门的语言，其中涉及到一些专业词汇，避免沟通障碍。和客户沟通明白需求，和程序员沟通....选择技术：如何选择使用的技术，要考虑的事项（如：架构师本人的技术，对于软件的性能，不同架构一起融合等）性能：相对于功能而言，性能经常被忽略。——————作者：H100来源：CSDN原文：https://blog.csdn.net/u014449046/article/details/49390571版权声明：本文为博主原创文章，转载请附上博文链接！
据预测，未来 10 年中，企业或组织的数字化转型会达到高峰，将比过去几十年的总和还要多。而这一进程，开发工程师必须找到更加有效的开发方式，才能实现。在这一层面来说，DevOps 是数字业务转型计划的核心。目前，企业越来越重视DevOps，并开始向这种开发方式转型。但是，如此多声称专注于 DevOps 的企业或组织，真的都做对了吗？在大多数的 DevOps 实践中，仅仅涉及到了特定工具的使用，企业非常松散地遵循着某些 DevOps 原则。然而，要想真正成为一个以 DevOps 为中心的组织，这些远远不够。参照以下 7 点，或许能够帮助你及时纠偏：一、部署是完全自动化的每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分，要想将这些部分有效组装、最终形成最后的应用结果，往往需要借助构建工具或策略。构建过程如果仅仅依赖人工，就会十分繁琐。于是，自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现，将大大提升工作效率。在 DevOps 实践中，是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间，更多是避免问题的出现，手动部署更常出现因为人为错误引起的问题，而自动部署可以在问题出现时迅速恢复到以前的版本。二、有频繁且快速的发布周期天下武功唯快不破。想要获得更强大的竞争力，只有不断部署和快速修复。DevOps 中一个核心功能就是 CI/CD（持续集成/持续交付），寻找更有效的自动化和部署更新迭代的方法，让开发人员提高生产效率、并快速地发布到生产环境中。CI/CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于：1）通过频繁的代码库提交、自动化构建等来提高生产力；2）通过集成自动化测试以及开发期间的测试，增加在开发早期发现错误的机会；3）得益于频繁的测试和自动化部署系统，可以更快地发布版本。三、注重可观察性国外的一份报告显示，可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中，可观察性有非常重要的意义。New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现，90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉，才能作出明智的决策，越来越多的团队开始从整个企业应用程序环境中收集数据，来提高整个开发过程的可观察性，可观察性也在生产前和生产后的环境中扮演越来越重要的角色。四、有持续的反馈循环初期，DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现，有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环，如上图所示。其中，蓝色气泡代表技术，黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环（黑色箭头反馈环）；开发-运维反馈环（绿色箭头反馈环）；业务-运维反馈环（红色箭头反馈环）；业务-用户反馈环（紫色箭头反馈环）。在现在的 DevOps 理念中，出现错误并不可怕，可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知，从而使问题得到更快地解决。很多时候，我们遇到问题仅仅是简单地解决了它，并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上，如果你设置了一个系统来识别问题、修复问题和改进问题，还需要认真分析，才意味着你在正确地实践 DevOps。具体来说，一个监控系统需要观察并记录系统状态变化和数据的流程：1）状态的变化：可以通过状态的直接度量或者更新日志来表示；2）数据：可以通过记录内部组件和外部系统之间的请求和响应来记录。五、开发和运营团队一起工作Dev（开发） 和 Ops（运维） 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出，并以“Cooperation”作为整个演讲的核心，讲述了他们解决这个矛盾的实践经验。在一个组织中，如果相关利益者的利益不一致，在既定流程的进行中一定会碰到诸多阻力。而在这一点上，首先做的就是把 Dev 和 Ops 的利益一致化，从而减少 Ops 对软件交付的阻力。在传统观念中，开发的工作是增添新的功能，而运维的工作则是保证站点的稳定和高性能。 而在 DevOps 的观念中，Ops 的工作目标应该是激活业务（enable the business ），与 Dev 是一致的。至此，DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上，DevOps 的解释也着重于一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。因此，开发、测试和 IT 运维团队之间的沟通对于 DevOps 的成功至关重要。六、目标明确虽然不同团队之间的沟通至关重要，但明确定义每个人都在努力实现的目标同样重要。归根结底，所有团队都有同一个目标：让组织更有效率。但是，他们为实现这一目标而遵循的个人实践可能会有所不同。团队成员应了解实现目标所需满足的精确要求，而不是做出假设或任其发展。七、使用正确的工具和平台DevOps 不仅仅是一种文化转变——它需要强大的工具才能实现。在实践过程中，如果你发现往往需要花费大量时间来解决出现的问题，那么很可能是因为你没有选择正确的 DevOps 工具。幸运的是，目前的市场上有大量且广泛的 DevOps 工具可以选择，以适应当前现有的所有的数字化基础设施。尽管工具是 DevOps 的重要组成部分，但是要记住，真正使改变发生的是实践。在众多 DevOps 工具中，近两年来被业内广泛关注的飞算SoFlu因其对软件开发流程的变革而被大量企业应用于DevOps落地，飞算SoFlu是一款管理加开发工具，通过可视化编程的方式满足开发需求。使用平台的一个ID相当于一个10人科技团队，从而使用户有更多精力可以更多关注自身业务。飞算SoFlu中包含的三大核心技术，全都是 DevOps 实践中所要关注的重点：1）可视化开发改变传统开发方法，业务逻辑可视化展示，降低开发门槛，无需编写代码，在设计业务逻辑时就形成微服务应用。2）平台组件可视化平台组件是一类通用的技术功能模块，平台支持循环条件判断，函数调用，通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑，有别于通过组件排列组合。3）管理方式主要通过管理平台来管理需求、研发、测试、部署、上线、运维等整个软件生命周期，经验沉淀、知识积累，将管理制度真正的落地。截至目前，飞算SoFlu已为包括医疗、金融、制造、零售等在内的八大行业的上百家机构提供了技术服务，助力其落地DevOps，提升研发效率。一个典型的案例是，飞算SoFlu在某大型国有银行的应用。该银行原本需要3天才能开发完成的接口，使用飞算SoFlu，仅用了5个小时。其IT负责人表示，使用飞算SoFlu后，银行软件中心的整体研发效率获得了大幅提升。飞算SoFlu的DevOps功能正是在不断的实践中完善升级，从实际业务出发，真正让企业实现降本增效。
交付物软件100%实现需求明细列表所有功能，即100%满足业务需求的软件。文档项目验收验收方式1、将要交付的软件安装于指定服务器，并完成调试和上线；2、完成培训后，业务验收人员根据需求明细列表实现情况进行验收评价，研发验收人员根据以下内容进行验收评价。文档验收1、文档齐全（参考如上文档清单）；2、文档内容描述准确, 没有歧义和错误的表达；3、文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；4、文档对主要功能和关键操作尽量提供应用实例。界面验收1、界面设计符合自己公司的设计规范；2、外包团队需提供与软件适配的浏览器、手机、PAD等品牌与版本号清单；3、各界面需要做好PC、手机、PAD等UI兼容与机器适配；4、原则上，浏览器至少需适配Chrome、Safari、火狐、IE8以上；5、原则上，手机至少需适配苹果、小米、华为、vivo、OPPO、三星、魅族。功能验收1、功能验收范围覆盖（接口、数据库存取、页面功能）；2、提供单元测试用例、集成测试用例和系统测试用例；3、提供BUG管理跟踪记录表；4、提供质量分析报告。性能验收1、提供性能测试报告；2、相关重要指标达到以下要求：安全验收1、软件中的敏感数据需以密文方式存储；2、软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等；3、软件中各种用户的权限分配合理；4、扫描出的安全漏洞（包含但不限于：越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等）外包团队需修复完毕。用户验收1、外包团队需提供稳定的用户验收环境和联调环境；2、业务场景功能测试不通过数的比例<1.5%；3、不存在严重等级为1的错误；4、不存在严重等级为2的错误；5、严重等级为3的错误数量≤5；6、所有提交的问题都已得到修复；7、以上功能，用户验收测试通过后，由用户负责人签署验收通过确认书。源码交接如涉及到源码交接，按下列规范进行验收和交接。交接前提条件1、需提供用户验收通过确认书；2、涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块；3、跟薪资类无关的软件或功能，所有功能需在线上稳定运行不少于3个月；跟薪资类相关的软件或功能，所有功能需在线上稳定运行不少于6个月；4、线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个。源码验收1、代码应只保留跟本项目相关的代码，无效代码应一律去除；2、数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等，无效内容应一律去除；3、特别注意合理做好数据表结构设计，适当冗余提升性能；4、代码结构清晰无冗余，注释完整有效，避免硬编码；5、但凡不符合源码验收规范的，外包团队需修复完毕。其他注意点1、对于外包团队的软硬件选型，建议业务部门邀请本公司IT团队一起参与决策；2、与外包团队商签署的商务合同和补充协议等，建议业务部门邀请本公司IT团队一起参与制定；3、外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可；4、如外包项目不符合或无法满足上述验收规范的，建议商务层面延长付款周期、扣除相应款项或终止合同；5、每一笔合同款在支付给外包团队之前，除了需获得用户验收通过确认书之外，还应通过IT团队验收；6、以上内容建议附加进商务合同，成为其中一部分。
软件外包存在风险，外包人员技术、态度、交付能力，如果想通过合同或者诉讼降低风险，由于太多的未知因素和太多的主观性，不现实。因此唯一的外包原则应该是：如果外包人员做得不好，有能力随时终止合作且可控费用损失和项目交付。可以尝试渐进式方法，首先废除传统开发外包大瀑布方式（例如签订需求URS、项目总金额、进度款支付）（不过目前大部分外包会坚持使用瀑布法，并签订大额的预付合同），尝试新方案，项目按照功能或者阶段划分为多个子合同，做小项分包，或者改为签订人力外包合同。针对我们想要构建的功能，拟定一个顺序列表。找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。让他们实现那个特性并测试。让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。符合要求后，合并并部署该特性，这样，所有创始人/用户就可以继续审核该 App，并提供反馈或者根据需要调整。如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。如果我们对他们的工作不满意，就解雇他们，并寻找替代者。当前需要做的工作，整理敏捷开发平台或者公共开发平台，并且参照以下原则：客户合作胜于合同谈判个体和互动胜于流程可运行的软件胜于详细的文档响应变化胜于遵循计划参考文章：Experiences working with an Outsourced Dev Shop
亲测推荐 2021 年 SaaS 技术栈：Docker、Django、Traefik 和 IntercoolerJS
我最近发布了个人对Django做为一款优秀应用框架的一些考虑。本文基于此从架构角度做进一步扩展，介绍从开发到生产环境的整体技术栈考虑。2018 年至今，我一直使用该技术栈构建一些小型 SaaS 应用。本文最初发布于 www.simplecto.com，经原作者授权，由 InfoQ 翻译并分享。整体技术栈随处部署的 Linux 服务器和虚拟机：我使用了 Azure、Digital Ocean 和 Scaleway，并计划在 2021 年将所有部署迁移到Hetzner提供的专用服务器上。Docker：就是我们常用的 Docker.Traefik：使用 LetsEncrypt 证书的反向代理和 TLS。Postgresql：运行在 Docker 中的数据库。Django：同样运行在容器中。IntercoolerJS：提供平滑易用的类 Ajax 前端应用支持。Intercooler 的创作者在 2021 年发布了HTMX，是 IntercoolerJS 的更新换代。Sentry：捕获生产环境中软件缺陷。只需在配置文件中添加几行配置。Bitbucket Pipelines 替代 CI/CD：鉴于 CI/CD 引入了过多繁琐无用的工具，我在 2021 年不再对个人项目考虑 CI/CD。ZeroTier：实现 VPN 和控制层。我在开发小型项目时，采用本地 Docker 容器运行测试，进而直接推送到生产环境。我不考虑使用繁琐的 CI/CD，而是选择了 Bitbucket Pipelines。上图给出了我所采用技术栈的概览，图中有很多需要详细展开阐述的部分。下面换成列表方式展示。虚拟机DockerDjango挂载数据磁盘卷使用长时间运行 Django 命令做为 Workers挂载数据磁盘卷Postgres挂载数据磁盘卷TraefikZero-TierSSH托管环境即便是无服务器架构，也需要一个云服务托管环境。我个人推荐Azure、Digital Ocean和Scaleway。每家都为计算、联网、存储和基本服务提供了充分的选项，支持用户任何构建需求。同样推荐Hetzner，它提供了各服务层级的硬件、服务和价格。虚拟机一些企业应用和个人副业（side projects），并不需要同时为成千上万的用户提供 TB 级数据服务，因此可扩展性并非主要关注问题。对于此，我们可选用最小托管服务选项，通常不高于每月 20 美元。即便是服务价格相对最贵的 Azure，也可选用 Burstable 服务质量的虚拟机。个人推荐Scaleway的开发层级服务器。注意：在我的技术栈中并没有 Kubernetes，因为我并未考虑可扩展性。Docker为确保新的虚拟机运行在最新版 Docker 上，我并没有依赖操作系统本身，而是使用了 curl|bash 方式，即：curl -s https://get.docker.com | sudo bash 运行上面一行命令，就能获取最适用于当前运行环境的最新版本。Traefik 实现反向代理Traefik 对我简直是天赐之选。尽管 Nginx 也很强大，但其并非针对 Docker 环境构建。Traefik 的两个杀手级特性，为我节省了大量时间：使用 LetsEncrypt 实现自动 TLS。简而言之，一旦设置，无需操心。结合适用的 API 和 DNS 服务提供商，还可以使用 DNS 验证。使用 Docker label 实现无需重新加载的自动配置。一旦新服务发布，Traefik 通过监听所有 Docker 相关服务而自动发现更改。这使得服务的添加、移除和合并非常方便，不存在任何麻烦。我对 Traefik 唯一意见是学习曲线略为陡峭。用户必须自行确定如何进行配置，包括配置文件、命令行选项、YAML、Docker label，乃至组合使用。提示：我发布了自己使用的Traefik生产环境配置文件，供参考。Postgres 数据库亲测推荐，PostgreSQL 从不会令我失望。PostgreSQL 容器可毫无问题地添加到任何项目中。我只需简单地启动容器，绑定端口，挂接数据卷到主机磁盘，仅此足矣。docker-compose.yml version: '3.1' services: db: container_name: postgres hostname: postgres image: postgres:11 restart: always environment: POSTGRES_PASSWORD: secretsonly volumes: - ./data:/var/lib/postgresql/data ports: - 5432:5432 networks: - web networks: web: external: tr 用于 Web 的容器化 DjangoDjango 很好地支持发布到容器中，我多年以来一直这么用。我反复强调开发环境和生产环境匹配的重要性，Docker 为我实现了一切。我在 2021 年新推出了一个 Django 项目，用做新项目的模板，参见https://github.com/simplecto/django-reference-implementation。实现异步任务的 Django 命令我使用做为标准框架组成的自定义Django命令实现异步任务。该模式采用具有 sleep()的 while 循环，轮询数据库相关操作，并采取相应的动作。截止 2021 年，我已使用这一模式运行一个网站截屏项目一年多，回报丰厚。该项目每日对 1500 个网站做截屏，所有操作由 Django 命令计划和管理。项目地址：https://github.com/simplecto/screenshots。IntercoolerJS 降低了复杂性这里如果展开说，需推出多个帖子，恐怕内容太长，以至于不会有人愿意读。我结合 JQuery 和这个小型 JavaScript 库，实现部分类似单页应用的效果，尽管事实上并非单页应用。IntercoolerJS 保留了 Ajax 的传统优点，从后端 HTML 更新 DOM，无缝且平滑，非常便于实现用户登录和更新小型表单等元素。强力推荐访问IntercoolerJS官网。其创立者在 2021 年继承发展了 IntercoolerJS，推出了HTMX。Sentry 捕获生产中错误任何应用都会出错，但不应向用户展示。Sentry 提供了一种捕获生产中软件缺陷的易用便捷方式，其特性包括：开源许可，可在生产中任意部署。只需在 Django 项目的 settings.py 中添加几行配置，即可生效。与 Git 代码库和问题追踪系统紧密集成，提供全生产环境的缺陷可追踪能力。另一个优点是，随时能在生产环境中禁用。更多信息，可访问Sentry官网。Bitbucket Pipelines 替代 CI/CD2021 年，我不在个人项目的部署中使用 CI/CD。其中存在太多工具，复杂性高。我只是使用 PyCharm 运行测试，然后从开发设备直接交付生产环境。当前存在多种 CI/CD 解决方案，但是我推荐 Bitbucket 提供的 Pipelines 的服务。该服务每月提供数百分钟的免费使用，只需很少费用就能提供自上而下的功能。我自己在使用中很少碰到问题，很喜欢它们的 YAML 配置文件。我使用 bitbucket-pipelines.yml 文件，实现跨多个 Docker 容器的完全端到端测试，加载数据库，并在几分钟内执行数以百计的测试。该服务是我们团队高效的关键，支持生产环境中每日五次以上 Push。更多信息，访问Bitbucket官网。ZeroTier 实现 VPN最后，推荐一种在很大程度上是可选的、但是最好应具备的技术。Zerotier 是一种独树一帜的网络/VPN 服务，我用其连接所有的个人计算机。它可穿透防火墙联通家庭和办公场所，一分钟即可配置好。如果所有设备使用 ZeroTier，就可以避免 SSH 中令人头疼的密钥管理，单机上共享带宽。Zerotier 可运行在 Linux、Mac、Windows、Android 和 iPhone 上，覆盖大部分设备。ZeroTier 的一个问题在于，我并不完全了解它的工作机制。和 MacOS 和 iPhone 类似，它们会按用户期望工作，并不出问题，只是从用户体验角度看有些不爽。但对于一名 CTO，谁又会去关心具体的细节呢？总结希望上面的深入介绍能激发读者对 Docker、Django、Traefik，尤其是 IntercoolerJS 的兴趣。它们简单、易于使用，能在适当时大展身手。原文链接： Docker, Django, Traefik, and IntercoolerJS is My Go-To Stack for Building a SaaS in 2021https://www.infoq.cn/article/W4leI4XZ32eSTqFJ8qPl
1概述2018年8月，工业和信息化部印发《推动企业上云实施指南（2018-2020年）》，提出到2020年行业企业上云意识和积极性明显提高，上云比例和应用深度显著提升，云计算在企业生产、经营、管理中的应用广泛普及，全国新增上云企业100万家，形成典型标杆应用案例100个以上，形成一批有影响力、带动力的云平台和企业上云体验中心。鼓励各地加快推动开展云上创新创业，支持各类企业和创业者以云计算平台为基础，利用大数据、物联网、人工智能、区块链等新技术，积极培育新业态、新模式。随着云计算的蓬勃发展，各个企业开始纷纷入云，但是在入云的道路上各自不同，根据企业的规模、技术特点、保密性的要求等，可选择的有公有云、私有云、行业云、混合云、集团云等等。本文主要讲企业在上云的过程中的一些要点，从为什么要上云、怎么上云、都有哪些考虑点、云上有什么样的技术，最后提供了上云实践的必要过程。2为什么要上云？企业的基础架构从传统的烟囱式部署专项云端部署，基于云计算平台的解决方案，已经成为企业管理者满足其业务战略的需求，快速实现其收益和效率的最聪明和最无缝的方式。云计算服务为公司提供了巨大的优势和工作量转移：IT部门不再需要购买、部署和维护内部的计算硬件和软件，可以通过云服务快速、容易地建立起来，无需IT人员参与就能根据需要进行扩展，并且会自动更新到最新版本。简而言之，云计算极大地简化和降低了IT服务提供的复杂性和成本。数字经济已经成为发展趋势，各企业都在进行或准备进行数字化转型，而上云则是企业数字化转型的起点。企业上云，主要有以下几点原因：■ 降低成本。企业运营需要成本，IT基础设施投入也是成本，大企业为了降低成本，提高集约化效果，形成企业内部或者集团内部的私有云、集团云；中小企业为了降低成本，选择公有云或者行业云、混合云；微型企业，无需投入建设机房、购买IT设备的资金，直接用公有云服务商提供的公有云服务。使用云计算服务，比购买一般的物理硬件要便宜得多，那么小微企业就可以摆脱很多不必要的开支。■ 高效弹性，灵活扩展。满足弹性、快速供给、快速释放的IT基础设施能力，才能更好的为业务服务。效率是企业的生命线，只有提高了生产率，企业才能在市场竞争中生存，云是提高IT基础设施效率的非常好的手段。■ 使云端数据更有价值。云带来了更大的灵活性和移动性，使用云，可以让企业在一台机器上开始工作并且在另外一台机器上完成它；企业对于庞大的交易、管理等数据做大数据分析，提供精准营销、分级客户管理等服务，使数据增值；人工智能更是基于大数据为基础，提供更加高阶的场景化服务。■ IT部门从成本中心转向利润中心。云的未来，不是一个成本中心，而是一个利润中心，它能创新很多新的业务模式，成为企业新的利润增长点。3上云的难点分析大中型企业的IT基础设施，一般都有比较重的历史包袱，如应用系统为部门级而非企业级、数据割裂且格式不统一、烟囱式部署架构、无法按需扩展等等，因此企业上云，主要有以下几个难点：■ 云化架构转型，需要建立相应的组织架构及人才队伍。从上层管理层到中层及下层技术人员，都要首先从意识形态上接收并主动拥抱云，理解云的架构、云的特点，建立起适合云计算发展的组织架构，培养响应的人才队伍，才能更好的做云化转型；■ 原有的IT架构，难以向云端迁移。云大多以虚拟化、开源技术、分布式技术为主，而原有的大多使用了大型机或小型机、相对重量级的中间件和数据库、以闭源厂商的产品为准，因此无法把现有的系统直接搬上云，必须要做云化改造；■ 原有系统复杂，系统需要重构。由于历史的原因所建立的系统必须要做重构，采用云化架构，使用适合云部署的技术，如虚拟化、容器化、微服务化，同时基础设施要建立相应的计算、网络、存储等资源池，采用计算虚拟化、软件定义存储SDS、软件定义网络SDN等技术、容器Docker等技术，提供IAAS、PAAS、SAAS、CAAS等云服务。4上云的方向选择企业上云，根据自身的特点，选择上云的方向，既要满足监管的要求、企业的需求，也要考虑自身能力，切不可能盲目跟风，选择与自身实力不匹配的方向，可以从以下几点考虑：■ 大中型企业。这类企业自身盈利能力较强，抗风险能力较高，IT基础设施投入较大，一般都会选择自建私有云，同时会考虑输出部分云计算能力给其他中小微企业使用，如某国有银行，不但建有内部使用的私有云，还有为集团、分行、子公司及外部客户使用的公有云，通过建信金融科技公司，提供从上到下的IAAS、PAAS、SAAS全套金融云服务；■ 小型企业。这类企业因自身规模没有大中型企业大，IT基础设施投入相对要小，可以选择混合云或者行业云，自身因为数据保密的要求，将核心关键的系统建立在私有云中，对于不关键的系统可以使用公有云或行业云，以此降低IT投入成本。■ 微型企业。这类企业对于成本比较敏感，IT投入比较小，不会将能力过多的投入到IT建设中，可以选择部署在比较好的行业云或者公有云，甚至完全托管在其上，将精力聚焦在业务发展上，用最小的成本承载更多的业务。■ 监管要求明确的企业。这类企业一般都属于特点比较明显的行业，比如银行、证券、保险等，有银保监会、证监会监管，对于系统的高可用级别、灾备能力、数据安全等有比较高的要求，需要按照监管机构的要求，使用安全等保三级及以上的云。5上云的策略企业上云分为基础设施上云、业务系统上云和基础平台上云，在本文中主要以基础设施上云为主论述。5.1基础设施上云企业的IT基础设施主要包括机房、计算设备、存储设备、网络设备以及一些配套的安全（如DDOS、IDS等）、终端等，上云最主要解决的就是在这些领域都采用什么技术、怎么实现云化基础设施。■ 计算领域：可以采用vmware、kvm、xen、PowerVM等虚拟化技术以及docker等容器技术，提供IAAS、PAAS的服务。■ 存储领域：可以采用ceph等开源技术以及众多厂商提供的如vsan、FusionStorage等分布式存储技术，实现软件定义存储SDS、■ 网络领域：可以采用NFV、SDN等技术实现软件定义网络。■ 办公终端领域：可以采用ctrix等桌面虚拟化实现桌面的云化管理。5.2业务系统上云企业的业务系统在上云时不一定要齐步走一起上云，需要分批分步骤根据实际情况一步一步上云，分几种策略：■ 从外围到核心。先从外围系统不重要的管理办公类系统着手，做系统改造或者重构后上云，比如人力资源管理、办公OA、MAIL、考勤、日志管理等系统；其次选择重要性低的一般交易性系统，如渠道类的网站、机构管理、监控、呼叫中心等；最后选择核心交易类的系统，如网银、手机银行、信贷、财务会计、代收代付等系统；■ 从简单到复杂。先从WEB服务器、应用AP服务器入手，建立专部署WEB、AP的资源池，实现云化部署，再建立云数据库、分布式云数据库，实现数据库云，将所有基础设施实现云化部署；■ 集中力量从核心到外围。国内也有企业如某国有银行，利用建设新一代核心系统时，集中力量，做企业级建模将核心的业务进行了重构，分三期将除了IBM主机之外所有重要IT系统生产环境搬上了私有云，老系统逐步下线，完成了云化改造。那么，在上云的过程中，需要考虑哪些应用系统能够上云，哪些系统不上云，简单来说：重负载、IO高、响应时间要求高的系统不适合上云，笔者所在的企业在做系统搬迁时，ODS（操作型数据存储）系统的AP服务器在物理机上部署时，跑批时TPS可以达到1000左右，但是部署在虚拟化环境后TPS下降到300左右，跑批时间延长3倍左右，已经不能满足业务要求，经查是由于程序在写文件时，直接写盘和写经过vmware文件格式VMFS后磁盘时存在速度上的差异，导致TPS下降，采用物理机直接部署后问题不再重现，于是放弃了上云，还是采用物理机部署。业务系统上云，不是为了上云而上云，最重要是要能够发挥出云的特点，达到Cloud Native（原生云）的效果，实现CI/CD，devops一体化敏捷管理。要实现系统的敏捷部署、弹性扩展、动态迁移、故障自愈、数据更加安全可靠等，就需要系统在上云前做相应的改造或者开发新的业务系统来代替原业务功能，该如何做呢？主要从以下方面考虑：■ 新系统可以采用spring cloud等微服务解决方案，基于spring boot等框架，进行微服务改造，做到Cloud Native原生云系统。■ 系统部署方面，抛出传统的物理机、虚机部署，使用docker等容器等部署，采用主流的PAAS平台，基于kubernetes、mesos、swarm等主流框架，管理容器化的应用，实现开发、测试、运维的devops一体化管理，打通软件研发管理全流程。5.3基础平台上云除了基础设施及业务系统，对于一些通用的基础平台，如大数据、区块链、物联网、人工智能都是上云的方向，并且是未来的主流方向之一，不必重复建设复杂而又庞大的平台，直接使用云上的大数据、区块链、物联网、人工智能等服务，更好的为业务服务，开发更多的业务场景，提升资源使用效率，获得更高的利润。6云计算架构6.1云计算概述企业上云：选型，策略，架构，实践云计算在企业架构中主要与IT架构有关，与应用架构、技术架构、安全架构、数据架构都有关系。下图为IBM CCRA参考架构，定义了构成云计算环境的基本架构元素：企业上云：选型，策略，架构，实践企业上云：选型，策略，架构，实践云计算架构，有很多种描述，主要是以IBM CCRA模型为基础，每个企业在落地时有不同的特点，在此不赘述。简单来说，云计算是由计算/网络/存储等资源池、云服务、云管理平台、云安全等组件组成的，通过软件定义的方式为客户提供IAAS、PAAS、SAAS、CAAS等云服务。资源池是基础。资源池是云计算的承载体，主要包括计算、存储、网络等资源 。没有资源池，云服务、云管理是空中楼阁，无法落地。云管理是平台。云管理平台对所有资源进行统一管理、调度，对资源进行全生命周期的管理。云服务是核心。将各种资源打包成服务，由云平台调度，为使用者提供服务，主要提供IAAS/PAAS/SAAS等服务虚拟化、容器等都是资源池的实现技术基础，有了虚拟化、容器技术，可以更方便、快捷的提供IT基础设施服务。6.2资源池云计算最基础的是资源池，涵盖计算资源池、存储资源池、网络资源池等，计算资源池又分、X86虚拟化资源池、POWER资源池、Mysql/Redis资源池、大数据资源池、GPU资源池等等，主要有以下几类：1、X86虚拟化资源池。以vmware esxi、kvm、xen等技术为主，私有云采用vmware较多，公有云及行业云等主要以kvm技术为主；2、小型机资源池。以PowerVM为主，主要采用Power虚拟化技术；3、裸金属资源池。为用户提供裸金属服务器，满足部署不适合做虚拟化部署的需求，主要以X86服务器上安装Oracle RAC、Mysql、以及应用软件等；4、大数据资源池。部署大数据类基础软件，存储、计算大量数据，挖掘数据价值。序号资源池类型主要功能不适合功能1X86虚拟化资源池Web、Ap数据库2小型机资源池DBweb3裸金属资源池重载AP、DBWeb4大数据资源池数据分析Web、ap6.2.1网络区域规划资源池需要部署到实际的网络区域中，比如传统的金融企业一般会分为几个区域：企业上云：选型，策略，架构，实践1、内网业务区。该区域主要部署内部系统的区域，基本上企业核心的系统都在此部署，属于一个功能完备的区域，既有WEB、AP又有DB、大数据等；2、运行管理区。该区域主要部署保障IT系统运维正常运转的维护管理类系统，如监控、安全审计、批量调度、运维大数据等；3、互联网DMZ区。该区域主要起到隔离互联网与内部网络的作用，互联网业务请求通过该区域服务器做交易的转发（交易不落地）到内部业务区域做业务处理；4、外联网DMZ区。该区域和互联网DMZ区起到相同的作用，不同的是所连接是外部合作机构，而不是互联网渠道，相对互联网来说，外联网所连接的机构相对可信一些。6.2.2资源池架构云计算最基础的是资源池，涵盖计算资源池、存储资源池、网络资源池等，计算资源池又分、X86虚拟化资源池、POWER资源池、Mysql/Redis资源池、大数据资源池、GPU资源池等等，下面我们以使用最多企业内部使用的私有云X86虚拟化资源池和Power数据库资源池为例，大致说明资源池的架构。■ X86虚拟化资源池某企业采用的X86虚拟化资源池，以CDP（云部署单元）为单位，每个资源池可以包含N个CDP，每个CDP包含3个独立的集群，每个集群包含16台X86服务器和1台NAS（做root盘），保证各条通路的相对独立性，避免生产故障蔓延，应用的部署单元以3的倍数部署，保证高可用。这个架构的高可用性是很高的，基本从底层、网络、服务器、板卡、接线等硬件层面到上层的应用部署都考虑到了，运行六七年来未发生过生产事故，资源池物理部署图如下：企业上云：选型，策略，架构，实践■ Power资源池Power服务器在企业中使用还是比较广泛的，虽然近年来受到互联网去IOE架构的影响，很多互联网企业甚至一些小的企业不再使用，但是在中大型及一些高可用要求高的小企业中使用还是很广泛的。基于PowerVM虚拟化技术，构建Power资源池，是很多企业采用的策略，尤其是银行、证券等金融行业。Power资源池提供全面的HA + LPM（在线分区迁移）+ RR（远程重启）+ GDR（容灾）一站式高可用方案，相比传统物理机HA方案增强了高可用，消除了高可用的盲区。Power资源池是基于企业级高端虚拟化+架构的最佳实践，并非泛指的云平台，可以承载原先小型机、PC服务器平台运行的几乎所有业务，通常建议可用作除关键业务外的大部分数据库及应用的整合平台，有以下的好处：分配同等虚拟资源情况下，相对与同代Power物理服务器提供相当性能，并通过高端服务器整合提供更高的弹性性能和扩展性；对于整合旧Unix、PC服务器的场景，提供多倍于原系统的开放平台最高单核性能来加速应用，并提供更大的性能弹性和扩展性；少数需要极端网络、存储IO吞吐量和响应时间的应用，建议单独评估测试；典型软件包括数据库、中间件、各类企业软件套件如ERP、自研应用等。Oracle/DB2/WAS/SAP等主流软件都认证PowerVM虚拟化并有大量部署案例。典型的应用场景示例：银行：除核心、前置等最重要一二十套系统以外的数据库、应用等；政府：除几套关键系统外，其他数据库、中间件服务器整合；企业：ERP、数据库服务器整合。企业上云：选型，策略，架构，实践6.3云服务我们常说的云计算的云服务主要分为三种：IAAS、PAAS、SAAS（随着发展衍生出很多种XX即服务，最基础的还是这三类）基础云服务。6.3.1基础云服务IaaS: Infrastructure-as-a-Service（基础设施即服务）。提供给消费者的服务是对所有计算基础设施的利用，包括处理CPU、内存、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。主要指为客户提供安装了最基础的OS的虚机/物理机，提供最基础的计算能力。PaaS: Platform-as-a-Service（平台即服务）。提供给消费者的服务是把客户采用提供的开发语言和工具开发的或收购的应用程序部署到供应商的云计算基础设施上去。通俗说就是安装了weblogic、tomcat、mysql中间件或数据库产品的虚机/物理机，可以直接供客户进行软件部署或者开发/运行环境搭建等。SaaS: Software-as-a-Service（软件即服务）。提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户可以在各种设备上通过客户端界面访问，如邮件系统、CRM客户管理等。消费者不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等等。在企业内部IT基础设施云，我们一般的关注点在IAAS和PAAS，为企业业务系统提供快速、弹性、敏捷、高效的基础设施服务。如下表是常见的IAAS及PAAS服务：序号服务类型云服务名称配置适用场景1IAASRedHat Linux 7.5 通用服务CPU(C):1/2/3/4/…32内存(G):1/2/3/4…..128磁盘(G):root 100 data 200Web/AP2IAASAIX 7.1 TL04通用服务CPU(C):1/2/3/4/…32内存(G):4/5/6/7/8…..128磁盘(G):root 300 Data自选DB/AP3PAASRHEL 7.5+WEBLOGIC11G同IAAS配置AP4PAASAIX 7.1 +Oracle RAC 11G同IAAS配置DB6.3.2高级云服务除了传统的IAAS、PAAS、SAAS服务，还可以考虑发展更高级的云服务，如云数据库RDS、分布式缓存、函数调用、云应用市场、GPU、物联网、人工智能、机器学习等云服务，甚至可以使用serverless云服务。下面主要介绍一下RDS及物联网、人工智能的云服务。■ 云数据库RDS云关系型数据库（RDS）是一种稳定可靠、可弹性伸缩的在线数据库服务，支持MySQL、SQL Server、PostgreSQL、MariaDB等引擎，并且提供了主从热备、容灾、备份、回档、恢复、监控、快速扩缩容、迁移等方面的全套解决方案，无需DBA过多干预就可以快速提供数据库服务。如下图是一个典型的RDS云数据库的架构：企业上云：选型，策略，架构，实践■ 物联网物联网（The Internet of things），是在“互联网概念”的基础上，将其用户端延伸和扩展到任何物品与物品之间，进行信息交换和通信的一种网络概念，是信息科学技术产业的第三次革命。下图是物联网的四层架构，主要分了感知层、传输层、平台层和应用层，其中，感知层是物联网的底层，是物联网应用和发展的基础。利用RFID技术、传感等技术，实现对物理世界的智能感知、识别及控制等。物联网的传输层分为有线传输和无线传输，无线传输可按距离分为短距离传输和长距离传输，主要讲述无线传输。物联网的平台层分为四大平台，分别为连接管理平台（CMP）、设备管理平台(DMP)、应用使能平台(AEP)和业务分析平台(BAP)。平台层用于数据的分析与处理，后应用于各个行业。企业上云：选型，策略，架构，实践■ 人工智能人工智能（Artificial Intelligence），英文缩写为AI。它是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。人工智能的云服务可以分为很多种，如智能语音识别与交互、人脸识别、图像识别、自然语言处理、机器学习、数据可视化等。人工智能的技术可以应用很多很广的场景及业务，不仅限于业务，人工智能技术也应用在了银行IT运维工作中，如数据中心的智能化运维AIOPS，使用海量运维数据，发展智能运维，自动发现问题、分析问题、处理问题，达到系统故障自愈，还可以利用态势感知，对故障进行预测等。■ Serverless未来的应用应该是不依赖于底层的虚拟机，而是建立在一些serverless的云服务之上，例如开发一个应用，直接使用云上的负载均衡，调用云上的身份认证，使用云上应用市场的服务，把数据存放在RDS中，然后用云监控进行故障分析，用服务治理进行相关的服务监控及调优，使用devops提升效率…这种云模型的高级使用，彻底抛弃了自行申请操作系统并安装中间件数据库的方式，也是应用上云的架构改变。serverless架构主要包括BaaS（后端即服务：Backend as a Service）和Faas（函数即服务：Functions as a Service）这两种架构，他们没有一直运行的定制服务存在，不占用服务商的计算资源，同共享单车有些类似，是计算机分时租赁方式，按次按时计价。Serverless主要的优势是低运营成本、简化设备运维、提高可维护性、更快的开发速度。缺点是目前还少有大型成功案例，无法适应所有的场景。6.4云管理企业上云：选型，策略，架构，实践有了资源池、有了云服务，如何将各类资源池有机结合在一起管理，实现快速、敏捷、高效、弹性的提供基础设施服务，需要云管理平台来解决，在云管理平台路线选择上每个企业都是不同的，但是主要由几种方式，做个简要介绍：■ 开源Openstack。采用开源Openstack，可以利用开源社区的优势，获取知识较快，落地相对也较快，但是需要投入比较熟悉Openstack的人员自己研究、测试、持续跟踪、升级，尤其是在没有外部专家人力的情况下，升级、迭代会比较困难。■ 自主研发。自主研发云平台最大的好处是贴近需求，可以把企业所有的资产管理、IT流程、自动化、配置管理等所有集成在一套平台上，提供端到端、场景化的IT基础设施服务，难点是投入大、开发周期长，而且必须要持续开发。■ 商业产品。采购一款商业产品（可以是厂商闭源厂品或者OpenStack商业化产品），这种方式见效最快，但是不一定完全贴近需求，往往需要二次开发。6.5云安全企业上云后，系统的安全性会集中暴露出来，不管是网络安全，还是数据安全的维度，还是监管安全、企业风险安全的维度，同时云的技术特点决定了云上的安全与传统安全的区别。考虑云计算安全，首先要满足企业所在行业对信息技术安全的要求，如监管部门对金融业的要求，必须满足信息安全技术网络安全等级保护中第3级（即等保3级），部分核心系统甚至要满足等保4级的要求。下面是云安全所需要考虑的简单的云计算安全框架，可以从几个方面来考虑云安全：企业上云：选型，策略，架构，实践这个框架主要包括以下几个方面：6.5.1基础设施硬件安全基础设施硬件安全主要包括：■ 机房安全：顾名思义，机房安全主要考虑承载云计算的IDC机房的安全管理，涵盖region、az地点的选择、园区/机房的风火水电安全等，如机房供电要来自多个供电公司的独立变电所，防止数据中心全局性的单路供电全安全，为防止极端情况突然停电，还要有UPS短期不间断为设备供电，以及柴油发电机，应对长时间断电场景等。■ 网络安全：网络安全主要考虑网络服务要来自多个运营商、多条线路，防止网络中断等；外部、内部所有的网络连接、网络接入都要有多线路冗余，能够在单链路中断服务网络服务不间断等。■ 设备安全’关键功能的设备应采用高可用配置或采用其它技术手段使该功能不存在单点故障，设备应支持设备运行状态和资源的监控功能并支持在发生异常情况时发出告警；关键业务集群主机应跨机柜、跨机房或跨数据中心高可用部署等。6.5.2云计算软件安全云计算软件安全主要包括虚拟化软件、云管理平台、IT服务管理等软件的安全，也包括各类资源池的安全，如计算资源池、存储资源池、网络资源池等。■ 基础软件安全基础软件应从多个方面保证安全，如应确保接口之间进程调用通过认证；应具备内核补丁检测、加固及防止内核提权的能力；应保证用户接入云管理平台通信的保密性和完整性，应具备对基础软件漏洞及时发现并修复的能力等。■ 计算资源池安全计算资源池安全主要包括虚拟化软件的安全（如版本的选择，补丁、漏洞的修补等），资源池的管理上要有身份鉴别、安全控制、安全审计、入侵防范、恶意代码防范、镜像和快照的保护等。■ 存储资源池安全存储资源池同样包括存储软件的安全，以及管理上的安全等，如多层级访问级别控制和跨物理集群账号权限管理，要有数据的异地备份和备份数据一致性的能力，多租户间数据隔离的能力，多副本、加密、安全传输、故障自动恢复、数据快速恢复等能力。■ 网络资源池安全网络资源池安全主要考虑网络架构安全以及访问控制、安全审计、恶意防范、恶意代码防范等安全内容，如虚拟网络全冗余设计，保证无单点、提供应用负载进行弹性扩容的能力，在流量波动情况下也不中断对外服务，VPC隔离能力、网络流量监控、隔离能力等，6.5.3服务层安全主要包括IAAS服务、PAAS服务、SAAS服务的安全，其中重点的包括一些所选用软件的安全管理、数据安全、应用安全等，这里主要讲讲数据安全及应用安全方面。■ 数据安全数据是企业信息科技的核心资产，核心数据一旦丢失、泄露、被篡改、被删除将会对企业造成很大的损失，其安全性非常高。数据安全主要考虑数据在产生、传输、存储、访问、迁移、销毁、备份和恢复这些环节的安全性，如数据要分类标记、存储、保护，传输过程要加密、防范被破坏等，数据出生产区域要脱敏，控制数据访问权限，数据要定时备份、异地存储、验证恢复等。■ 应用安全应用安全主要考虑管理软件及业务SAAS软件的安全性，要有代码后门审查的能力以及对代码打包和发布进行管控的能力，要能够防范篡改、代码注入、DoS/DDoS攻击等，要有完善的交易日志、错误日志等，具备、黑白名单访问、应用访问异常情况进行监控识别的能力等。6.5.4安全管理安全的管理是一个比较大的课题，从宏观方面主要包括安全策略和制度、机构和人员安全管理、安全系统、安全运维等。在云计算中，安全也可以作为服务存在，安全即服务，将一些安全制度、安全策略通过建模、抽闲、归纳最终可以形成一些安全的应用系统和安全的组件，提供直接的安全场景服务或者供其他系统调用实现安全管理。如某银行在私有云建设过程中，基础设施安全服务层实现了终端安全、系统安全、网络安全、云安全等多个安全服务，应用安全服务层实现了用户认证、客户认证、密码服务、数据安全、安全监控等多个安全服务，形成企业级一体化的策略管理，对整个框架进行管理，各层服务进行管控，落实安全策略、安全管控要求，最终实现企业级、统一的、涵盖多维度的安全管理。7上云实践步骤7.1组织架构企业上云工程比较复杂、繁琐，可能需要从企业的价值链分析、建模，到业务流程的重构，再到应用系统的适配云化开发，再到基础设施的云计算环境构建，一环扣一环，需要上层领导重视、中层主导、下层实施，建立一体化的推进组织，才能更好的完成云化建设。7.2云化策略根据不同的系统实际情况，实施不同的策略：业务重构、系统新建。业务流程完全重构，开发新的业务系统，采用新的技术上云。业务不变、应用改造。业务流程不变，应用部分做改造，适应云化基础设施后上云。业务不变、包装上云。业务流程不变，应用基本不变，基础软件升级或替换后上云。业务不变、系统不变。暂不上云，待系统被代替自然消亡。7.3推进计划项目管理办公室（PMO）制定整体计划，并负责推进执行，并协调各方资源、职能处室、厂商等共同根据计划推进。7.4部署实施基础设施根据云计算整体规划、资源池方案、实施工艺、系统资源需求清单等，构建云计算资源池、供给资源，提供应用系统上线基础环境。7.5数据迁移根据老系统需求，做数据清洗、转换、迁移进入新系统环境，可以使用数据库迁移（如ADG、mysql主从同步等）方案、存储同步方案（NAS、SAN等）、工具迁移方案进行数据迁移工作。7.6应用上线最终，应用系统完成上线前的部署、技术测试、业务绿灯测试，将业务切换至新系统运行，可能涉及到多系统联合上线，并做好上线失败后的回退方案。■ 上线保障上线过程中，需要提供人员、车辆、通讯、工位、办公场地、食宿等后勤保障工作■ 网络切换包括网络访问关系开通、DNS切换等网络切换工作■ 平台切换包括操作系统、数据库的启动、运行正常，保证搬迁环境的系统部署一切正常■ 应用切换包括外部关联应用系统的切换（如指向原对外服务IP要改为指向新对外服务IP）、本应用的切换（停止原系统应用、启动新应用，新应用对外服务）等等■ 业务验证做完应用切换后，需要技术人员及业务人员做好业务验证工作，保证业务切换成功
网易将于 13 日正式发布基于 PAAS 的 IM 云服务“云信”。开发者可以通过客户端 SDK 和云端 REST API 让自己的应用快速轻松接入聊天功能。据介绍，网易新闻客户端的跟帖与私信功能采用的就是和“云信”一致的技术平台。网易表示，云信的背后是网易 POPO 和网易即时通等产品积累的长达 15 年的即时通讯开发经验。产品优势在于可以为开发者提供更成熟的样本经验、更丰富性的模式选择、更稳定的CDN服务（多节点）。官方资料称，网易拥有“业内最大”的服务集群架构，已成功发送1000亿条消息。经第三方权威测试，每日上亿条消息100%到达。基于POPO的私有精简二进制协议，可以提供更快的速度和更好的性能。对接入后的开发者，云信将提供7*24小时实时运维监控，技术工程师全天候响应，定期开展免费培训课程和技术沙龙。网易自己的网易新闻、网易云音乐、网易云课堂、网易花田等APP、以及顺丰快递、传化物流、家校无忧、企业书屋、上海清算所等单位都已经应用了云信的服务。网易云信