你好，我是爱因互动CTO，TGO会员洪强宁，在上一篇文章，我分享了程序员到架构师的发展之路，以及一名优秀的程序员需要具备的特质，今天我将继续跟你分享一名优秀架构师所需要具备的特质，以及从架构师转变为CTO的过程中需要注意的地方。
我觉得一名优秀的架构师，需要以下这四个关键能力：取舍、前瞻、抽象、容错。
一个架构总是有优有劣，它不会是完美的、普适的，也不存在一个架构在A场景能用，在B场景也最适用的情况，所以就需要我们准确判断，作出取舍。
我们可以根据具体的业务需求来调整架构，也就是以当前的业务需求，选出最匹配的架构。另外，架构师还需要根据现状衡量好需求和资源、效率和安全、时延和吞吐等等之间的关系，做出判断。比如对于在线系统，可能更重要的是保证它的高时延，因此就可以牺牲一定的吞吐量，而对于离线系统，吞吐量则更重要一些。
架构师需要具备一定的前瞻性，因为架构的调整周期比较长。这也是程序员和架构师之间一个很大的区别所在。
程序员负责一个项目，在当前的互联网协议下，项目的迭代周期非常快，基本以天或周为单位，最多一个月。如果发现不合适的代码，需要重构，程序员基本也能在几天或几周内就能完成重构。
而架构的调整是相对漫长的过程，可能需要数月，甚至要上年。因此，在设计架构时就需要架构师具备前瞻意识，对很多不确定的事情做出预判，比如未来访问量会增长到什么程度，会不会产生新的业务，这些会对系统产生什么样新的要求等等。
除了懂得取舍和拥有前瞻意识，架构师在设计架构时还要掌握抽象的方法，不能胡子眉毛一把抓，要做好分层和区隔。
因为架构师面对的是一个很庞大的系统，为了避免过早陷入细节，不要去看各个组件的细节，而是把它们的角色定义下来之后，再分块来思考。而在看每个分块时，其他分块都可以视为一个抽象的概念，另外，也需要考虑复用的问题。
举个例子，我们现在正在做的对话机器人，就运用了分层思想，并且高复用，一个对话机器人可以完成各种各样的业务需求。这其实是一个非常复杂的系统，里面有各种各样的对话机器人的模块，有的特别适合去做检索式的查询，还有的适合做任务导向的、产品推荐导向的对话等等。
我们把对话机器人抽象成一个通用的接口，再将它分为一个个小机器人。这样一来，每个小机器人只需要关注自己的业务模块就行了。然后，我们会在前端再引入一个路由机器人，由路由机器人根据当前对话管理的状态，来判断当前的对话应该交给哪个小机器人去完成。这就是典型的分层的思想。
相比程序员，架构师面对的环境要恶劣的多，因为系统复杂了，出错的几率也增加了，每个节点、每个功能都有可能出错，所以这就需要架构师为错误而设计，事先做好解决方案。
除了出错，还有可能产生数据丢失的情况，这个可以通过备份来预防。有句话说“备份不做，日子甭过”，做好备份也是非常关键的。
另外，如果出现故障，该怎样去恢复呢？我们现在普遍的做法是不修只换，因为如果要修复一个异常状态，可能修复后还会出现连带问题，而如果能通过技术手段，删除已出现的故障，换一个全新的系统，就能够保证它迅速恢复到正常状态。
再来聊聊从架构师到CTO，我做CTO这个角色只有两年，相比资深CTO，我对CTO这个角色的感悟也没那么深刻。我觉得从架构师成为CTO之后，我工作中最大的变化是，从一个需求实现方变为了需求提出方。之前是我的老板提出需求后，我需要思考用什么样的技术和架构来实现它，而现在更多考虑的是，用什么技术才能发展业务。
怎样从架构师的角度转变为CTO的角度去思考问题呢，我认为关键点还是在于提高眼界，不仅要着眼于实现需求，还应该思考能发掘出什么新的需求。
举个例子，在我准备创业时，有一件事对我的触动非常大，就是AlphaGo战胜李世乭，我原本以为人工智能在围棋方面战胜人类还需要5到10年，没想到会这么快。
我以十年为一个节点，回顾了近三十年技术圈里发生的重要事件，发现大概每10年就会发生一件里程碑式的事件。
大约1986年年底，互联网正式商用，标志着我们进入了互联互通的时代。到了1995年，Web出现。然后在2007年左右，发生了三件大事，一是Google发表分布式系统论文，使得分布式计算变得更加廉价、更加可行；二是亚马逊发布AWS，意味着云计算正式进入可以商用的状态；三是苹果发布iPhone，标志着我们进入移动互联网时代。又过了十年，就是2016年，AlphaGo战胜李世乭，标志着我们已经进入了人工智能与大数据时代。
纵观这些趋势，站在CTO的角度，当前最应该关注的就是人工智能和大数据。而因为当时我们已经在做创业的准备，就需要考虑人工智能和大数据这个趋势会给我们的创业带来什么样的影响。
随后我和豆瓣前首席科学家王守崑就决定从这个方向入手，一起梳理了我们已经具备的技术能力，主要有这六点：自然语言处理的能力、深度学习的能力、个性化推荐的能力、知识图谱能力、大数据的能力和云平台的能力。
同时，对于产品，我们都认为，随着人工智能的发展，下一代的UI人机界面将会是对话式的，因为对话式的人机界面更加自然，门槛更低，又具有私密性和个性化的特点。所以，我们判断这样的产品会是未来的产品形态。
于是，我们就选择利用自然语言处理、深度学习、知识图谱等能力做一个对话机器人，利用个性化推荐、大数据处理、云平台等能力做一个SaaS平台。最终，我们的创业方向就确定为偏售前领域的对话机器人SaaS服务。
当我们成为CTO这个角色，往往不是先有需求，再考虑技术实现，而是根据当前的技术潮流和自己所掌握的技术能力，去考虑如何实现业务。
可能有人会说，这是CEO该考虑的事情，没错，这确实是CEO的职责，但也是CTO的职责。之前大家常开玩笑说，CTO就是要把CEO吹的牛含泪也要实现的那个人。我觉得不对，CTO其实是帮着CEO一起去吹靠谱牛的人，他是CEO的一部分。
CEO这个角色涵盖了公司中的方方面面，他把自己的角色拆分后，其中偏技术的角色就是CTO。同时CTO也是技术团队的建立者和技术文化的捍卫者，因为他是技术团队的最高负责人。
那么一名优秀的CTO应该具备哪些能力呢？
首先，他需要关注多个方面，第一，关注业务，我们需要知道用户需求，以及我们能够给用户带来什么样的服务质量和价值。第二，关注行业，比如竞争对手和新的技术，我们需要了解新技术对自己而言是不是意味着新机遇。第三，关注机遇，作为CTO，需要了解有哪些需求还没有被满足，我们能做什么，新技术能够带来哪些可能性等等。第四，关注增长，能预见到业务的增长并提前应对，能发现增长的瓶颈并及时解决，并在增长的过程中保持系统健康。
其次，一名优秀的CTO也应该是一名优秀的架构师，一般在初创公司，CTO就是首席架构师，公司的业务架构、技术架构，基本上都是由CTO来确定，再往前推进的。同时，CTO也是组织的架构师，需要考虑怎样搭建团队、怎样分解业务，才能够更好的完成战略需求。而对于战略，也需要CTO做出优先级判断和取舍。当然，CTO还需要发现并解决组织级的系统瓶颈，这和架构师做的事情是一样的。
同时，CTO也应该是一名优秀的程序员，但对于CTO要不要写代码这个问题，我的回答是“NO”。我觉得CTO最好不要写业务代码，因为，如果你没能及时提交，几乎没有人敢催，而这会影响项目的交付，成为瓶颈。如果你想保持对技术的敏感度和创造力，你可以写写效率工具，写写分析型的代码等。
最后，CTO还需要像程序员一样，持续不断的优化。当然，CTO要做的不是优化代码，而是优化产出，基于数据去管理团队。
职业发展的过程，就是眼界不断提高的过程。对于程序员而言，从写代码，到关注代码与代码之间的关系，再到关注代码与系统之间的关系，这时，他就开始承担了架构师的职责。
架构师主要是在做系统的事情，他的着眼点会从系统与系统之间的关系，到系统与业务之间的关系，到这时，他开始承担一些CTO的职责。而对于CTO而言，他关注的是业务，然后逐渐关心业务与业务之间的关系，最后关心业务与战略方向的关系。这个眼界提升的过程就是从程序员、架构师到CTO的发展路径。
洪强宁，爱因互动 CTO ，TGO鲲鹏会会员，资深Python程序员，曾任豆瓣网首席架构师与宜信大数据创新中心首席架构师，编程 30 余年，拥有11 年互联网从业经验。