《沉淀》是云栖社区展示专家风采的人物栏目。它呈现每个专家独一无二的人生经历、认识和感悟的同时，也能帮助你沉淀技术，收获对技术和人生的判断。我们的想法是：“若你想精进为一个很厉害的人，不妨细细品味这些技术牛人背后的沉淀。”
如果你想了解这些云栖专家更多分享时，请点击云栖专家频道，当然我们也欢迎你往前走一步，成为我们的云栖专家（https://yq.aliyun.com/expert），与技术大牛一起“煮酒论英雄”。
“客户第一”是阿里巴巴“六脉神剑”中排名第一的价值观，它除了要求阿里人服务好客户之外，也要求阿里的同学时时刻刻去了解客户的所思所想，不断地挑战自己，用不同的视角给客户创造更多新的价值。
在阿里云数据库DBA专家服务组里，就有一位技术人是“客户第一”的典范。因为他的存在，有客户放心地说：“我们才安心地把业务放在云上。”；也是因为他，客户非常感激：“如果没有他的帮助，可能会出现更加严重的问题。”
在服务态度上，有客户称赞他高效、负责；也有人对他的敬业动容：“感谢汪建明经常利用自己的休息时间来帮助我们查找和解决问题”。在专业上，有人赞赏他有高手风范，接手后不仅迅速找到了问题发生的原因，在半个小时之内还提出了解决方案，并帮他们完成了大部分的调优工作，及时阻止了问题向更加严重方向发展……
对于这些称赞，他没有一丝一毫地骄傲，反而不断地总结和反思，提炼出客户服务三步骤：了解客户诉求、做到情绪沟通以及坦诚方案风险。面对一时情绪上难以平复，“刁难任性”的客户，他真正做到：客户虐我千百遍，我待客户如初恋，问及乐观心态的原因，他笑称：“客户虐我们，恰恰说明他们爱我们，离不开我们。”
尤为值得一提的是他的技术，在上一家公司，他仅仅对一张核心表的设计优化，就为公司节约了30TB的SAN空间开销，带来的直接经济成本节约是两百多万人民币。为此，公司直接把他调往美国总部。
他，就是阿里云数据库专家服务组的汪建明，花名“风移”。第14期《沉淀》人物栏目，用时半个多月的时间，去走近这位在SQL Server数据库行业钻研十年的技术专家，将他的沉淀和别具匠心呈现给大家。
技能和职场快、准、狠的背后
汪建明说，数据是公司的生命线，而数据库是数据的最后一道防线，你对自己的所有操作的后果、风险一定要心中有底。
汪建明，目前在阿里云RDS负责数据库管理、运维、产品设计、研发，以及专家服务等。上一段工作经历，他是在新蛋（Newegg）成都公司做DBA。因为工作出色，几年后，他就被调到美国新蛋加州总部，负责集团数据库管理、运维、设计、性能调校，以及大数据平台建设。后者中，包括Hadoop、Hbase、Hive、Prosto和Phoenix等。
回顾这段较为顺利的职场经历，他把原因归结为四个字：“先知先觉”。他说，自己读大三时，就已经在企业里实习，摸爬滚打，锻炼自己。大四，更是几乎没在学校待过，一边自学大四专业课程，一边公司实习。
他说：“自己虽然累点，但是知识的吸收速度，和对社会、职场的贴近程度更快、准、狠。”在大四所有人都在为找工作东奔西走、忙里忙外时，汪建明已经在实习单位转正。
在转正后的四年里，汪建明做了无数的项目，也开始带领8个人的团队。随后，他转到美国总部。然而初到美国后，却让他有种一夜回到解放前的感觉。
问题体现在口语表达、文化差异、同事相处等方面。为了丰满自己，适应新环境，汪建明白天上班，晚上上语言社区大学语言课程，结束之后，再回家上在线英文课程。这是犹如孩童一般，从头开始一点一滴的重新学习：“如何打电话、如何点餐、如何与人沟通，甚至如何写英文邮件……”汪建明感慨到，文字表达有点苍白无力，其中滋味五味杂陈，只有自己才能体会。在这样的状态下，汪建明坚持一年后，也慢慢适应了新环境和工作节奏。
带来的I/O压力减轻和应用内系统的性能提升，很难用数字去表达
回首在新蛋的工作，汪建明称，因为做的项目太多，有很多都已无法记得特别清楚，唯独有一个记得十分清晰。
那是他发起并领导的一个项目，工作的内容是对一张核心系统表的设计优化。就是这张表，却为公司节约了近30TB的SAN空间开销。这个是直接空间节省，因此带来的I/O压力减轻和应用系统性能提升，很难用数字去表达。而这30TB的空间直接的经济成本是30万美金左右，也就是200万左右人民币。
他指出，这个项目是典型的利用技术手段，为公司节约经济成本投入的很好佐证。项目的背景是关键业务系统大表，表结构的设计有很大问题。具体体现在表字段类型的设计有问题和表主键设计不合理，比如好几个字段的数据类型被设计为CHAR（100）， CHAR（800），CHAR（2000）这种数据类型，而表主键则是CHAR(25)，这种设计导致的严重问题包括：
- CHAR数据类型存储了很多无用的空格信息，主键长度过宽，导致表聚集索引、非聚集索引空间占用过大
- 查询语句性能会消耗更多I/O资源，I/O利用率下降
- 索引维护工作超时，更进一步导致了查询语句性能低下
- 过大的表空间甚至导致备份超时，影响备份策略
问题的解决之道，也许并不是特别难，但让汪建明头疼的是：如何在完全不修改现有系统，不影响现有业务系统，在用户业务毫无感知的情况下，把这个项目按时按质量顺利进行；其次是，该表为大表，仅仅是这一个表记录数近1亿，表空间占用近700GB，数据源头同步到近60个数据目的业务子系统中，业务系统错中复制，盘根错节，千头万绪。
基于以上的同步关系，加之该表为公司关键业务系统表，公司里的技术人难以抉择。“我们不会也不可能直接在表数据同步源头直接修改表结构。如果这么操作会导致一个超大的事务，影响到所有业务子系统，对公司业务来说是致命的。” 汪建明道出难以抉择的原因。
这位在大三就在企业摸爬滚打的技术人，并没被问题吓住。他开始着手解决问题，先是理清楚所有业务子系统，该表的数据同步关系；接着，制定好详细的操作步骤，验证方法，不断在测试环境验证这些步骤和方法的可行性。
而当他不断探索，验证方案时，解决思路也就有了：在数据源头库新建一张中间表，中间表的表结构是已经优化好了，最终希望的表结构（CHAR数据类型修改为VARCHAR），不再存在数据类型的问题→在数据源头建立到中间表的Replication→确保正式表和中间表数据一致性→中间表上Update截断CHAR数据类型右边空格→在中间表基础上，参照正是表的同步关系，建立一摸一样的同步链→切换所有下游中间表，将中间表和正式表名字对调（这个过程很快，不到1秒即可完成）→最后切换最终源头表的名字。
当项目成功实施后，统计所有实例上该表空间占用情况，已然从700GB降低到200GB，空间占用降低了近70%，总共节约了近30TB的存储空间。项目总结时，所有人都对他竖起了大拇指。
技术不是僵硬的：“你仿佛看到了客人迎面而来，热情地紧握着你的手，满面微笑不断地说——谢谢。”
在美国待了三年后，汪建明意识到云计算的发展的巨大潜力和未来，他决定回国，并加入阿里。
来到了阿里云后，汪建明担任类似于“救火员”的角色，为客户解忧排难。对于他而言，每天面对的客人从之前的内部用户变成了外部用户，每天也都经历各种稀奇古怪的问题，管理数据实例的规模从几百到成千上万……正是这样异常复杂的环境，却逐渐让这位不善言辞的技术同学逐渐得到客户的认可，以及增强了他们对阿里云的信心。
正如文章开头提到，他受到多家客户表扬，包括复方科技、飞利浦中国、问卷星……等。令汪建明印象最深的是后来遇到的一家A公司。因为CPU持续100％，影响到公司业务无法正常开展，导致A公司的高层非常愤怒，几个工程师已经到了快要被开除的边缘。客户觉得阿里云RDS SQL不行，内部已经在准备着手应用下云或切换为MySQL。
而在他介入之后，通过分析“病原”。包括，闻：电话听取客户的抱怨、激动、怒吼和倾诉；问：询问“病状”表象，进一步确认“病原”；切：有针对性的实地考察，再次肯定“病原”。一系列组合拳后， 很快定位到CPU 100%的根源，开出治病良方。从索引缺失、索引碎片、Non SARG查询、数据类型隐式转化等角度，快速帮助用户解决问题，CPU也从100％降低到15％，查询语句时快时慢、卡顿和超时现象消失，应用恢复稳定正常。而更重要的是，那几个技术员不用被老板开除了，客户重新建立了对阿里云RDS SQL Server的信心，对阿里云充满感激，并发来热情洋溢的表扬信。
这次“行医”也颠覆了汪建明对技术的看法，他原以为技术是僵硬的，是死的，没有任何情感和情怀。“但从这个Case，我感受到了技术之外的魅力和情感。”他进一步述说，“在我看来‘简单’的技术问题，可能会要了客人的‘命’，也有可能要了技术人员的‘命’。而我们善用平时总结的技术知识点，运筹帷幄，一整套组合拳下去以后，客人反馈给我们的是有情感、有温度、有画面感的具体形象（你仿佛看到了客人迎面而来，热情的紧握着你的手，满面微笑的不断说，谢谢）。”
“这个或许就是技术带来的魅力，技术带来的情感，技术带给我们的成就感。”说完之后，他头转过来，从他的眼神中，云栖社区的编辑也看到了亮光。
如何炼就火眼金睛
如何做性能优化，汪建明表示，性能优化是数据库综合能力的体现。它涉及到数据库方方面面的知识和理论，比如：数据库设计（包括很多方面的设计）、查询语句写法、索引优化等。他觉得举一个实例比较好理解：“很多用户对于高CPU使用率问题是束手无策，我们可以从索引缺失、索引碎片、数据类型转化、non－SARG查询、统计信息、参数嗅探等角度多管齐下，很快就可以解决CPU高使用率的问题。”
而对于如何像他一样炼就一双火眼金睛，他也从以下角度给了两个诚恳的建议：
1.端正态度，不要操之过急。遇到任何问题，多想，多测试，多问为什么，要和问题死磕到底，不找到问题的根源死不罢休。多向高手学习，学习他们对数据库的理解、学习他们对问题的思考方式和解决方法；
2.多总结。按照类型总结，吃透一类问题（比如高CPU使用率的问题），那么涉及到这类问题的方方面面做到烂熟于心，信手拈来；
对于从事数据库行业的同学，他也给出一个忠告——和数据库打交道，一定要打起十二分精神。他说，数据是所有公司的生命线，而数据库是数据的最后一道防线，你对自己的所有操作的后果、风险一定要心中有底。
“试着问自己，如果这个操作导致了XX严重后果，有办法把数据救回来吗？数据会丢吗？丢多少？比如：我们经常遇到的Case是用户一个Update语句下去，忘记写WHERE条件，导致所有数据被Update，又或者是删除测试环境的数据，不小心连接到了产品环境等。”他说，类似的情况比比皆是，所以一定要小心再小心。
客户服务的三个有效步骤
每次帮客户解决完问题，汪建明并不是就此结束，而是会反复揣摩和进一步思考：如何能做的更好，如何能帮客户进步，让他们自己能避免一些问题发生。
在如何做的更好上，他提炼出客户服务三个有效步骤：
- 清楚客户需求：了解客户的诉求、需求点、痛点在哪里，客人迫切需要解决什么问题？如果客人是头痛，你却医脚。医术再高明，也解决不了客人的痛点。
- 情绪沟通：稳定客人的情绪，缓解客人的抱怨，控制客人的影响，做好舆情防范。在严重问题面前，最好能够当面和客人沟通，其次电话，再次即时聊天工具。
- 风险管理：坦诚解决方案的风险，让客人清晰、明了、理解问题解决方案的风险点，给足客人心里预期。
他还说：“我们不能要求客户，拥有像阿里云DBA那么牛逼的组合拳来面对问题。所以，有的时候，看到客人对我们产品的误解的时候——RDS SQL不行啊，要下云啊，又好气又好笑（这里笑没有贬低的意思，是苦笑）。气的是客人对RDS SQL产品本身研究不够深入，而武断下结论，甚至因此开除自己的员工；苦笑的是实际是一个不难的问题，却把我们的客人逼的焦头烂额，无从下手。”
为了让客户也能进步，汪建明哪怕是在客户服务结束后，也会对每一个问题都刨根问底，希望找到客户经常犯的问题的共性。他接受云栖社区访谈时，给出了自己的思考：
- 一切数据库技术问题的“祸根”或者说根源，可以归结为数据库的设计问题。比如：数据库架构的设计、分库分表的设计、读写分离的设计、表结构的设计、表字段类型的选择、索引的设计、索引维护策略的设计、统计信息维护等等；
- 对如何写出高性能的SQL语句没有感觉，开发人员往往是功能优先而忽视性能。比如：确保比较运算符两段的数据类型一致、WHERE字句中使用函数、Non－SARG查询等；
- 对SQL Server商业数据库能力边界没有信心。很多客人会问，SQL Server是不是不行了啊，是不是处理不了啊，是不是已经达到处理的边界了啊，Hold不住了啊等等问题。汪建明认为，这些类似的问题是很可笑的。如果SQL Server数据库用的好的话，PB级别不在话下。他之前的公司，单台实例的SQL Server数据量达到20TB以上的数据量，照样稳定高效运行。“现在公有云用户没有谁达到了这个量级吧？”他反问。
至于如何实践，汪建明说：“除了自己不断学习，不断总结，也可以多看看云栖社区上的技术分享和总结。”他说，站在前人的肩膀上，总会站得更高，看得更远，少走弯路，更快成熟。为此，他还把自己十多年的沉淀和针对性的总结，做成专题，详情参见链接：
https://yq.aliyun.com/topic/98。
他也指出：“当然，作为阿里云RDS这个角色，如何将我们的经验、总结，以及我们对数据库本身的理解，沉淀出产品来，使得用户入门的门槛更低，运维、设计、管理更为方便，也是我们必须要突破的重点和难点。目前也有一些服务出来，包括专家诊断、专家服务和个性化的培训服务等，详情参见专家服务：
https://promotion.aliyun.com/ntms/act/clouddba.html。”他也表示，自己实际上不是一个人在“战斗”，背后也有一排排同样专业的技术大牛，这么多人构成了ApsaraDB专家服务多样化、个性化、全面和周到的服务体系。
结束语：知行合一
在最后，我们聊到对技术的理解。他说，不论是技术人，还是技术型公司，都需要对技术的执着追求、对任何问题死磕到底的工匠精神，戒骄戒躁；以技术解放生产力问题，用技术提高生产率，优化产品质量。
“这就是我对技术和对技术从业人员需要具备的特质的理解。”说完后，汪建明又补充，
这里还想借王国维人生的三个境界，进一步来阐述他对技术的认知。
第一层境界：昨夜西风凋碧树，独上高楼，望尽天涯路。他解读，但凡活好，技术牛逼的技术从业人员都有明确目标，执着的追求。“独上高楼”，登高望远，讲的就是对目标和方向的明确，一旦找准方向，哪怕独自前行，风雨征程，也绝不退缩，永不放弃；
第二层境界：衣带渐宽终不悔，为伊消得人憔悴。任何成大器者、大学问者，都不是轻而易举，唾手可得的。坚定信念，一番辛勤劳动，废寝忘食，孜孜以求，直至“衣带渐宽终不悔”。汪建明还描述到：“此刻，我脑海中浮现这样的画面：在无数个孤独的夜晚、夜深人静、唯有码农还在挑灯夜战，陶醉在代码的世界里，醉心于诗一般美妙的代码逻辑中，为着对技术的追求苦战到底。”他说，所以你会发现现实中的码农都是骨瘦如柴、满脸倦意、不修边幅、睡眼惺忪，邋里邋遢（汪建明笑称这里都是贬义词褒用啊，哈哈），这是“为伊消得人憔悴”的体现；
第三层境界：众里寻他千百度，蓦然回首，那人却在灯火阑珊处。最后一个境界，可谓是苦尽甘来，在我们持续专注、沉下心来、潜心研究、下足功夫、融会贯通、有所发现、有所成就，我们自然会达到浮躁渐去，成就、成果自然就会在“灯火阑珊”处。这是我们坚定信念、戒骄戒躁、执着追求的必然结果。
言之至此，笔者想起，访谈中多次在钉钉上找他，他无一例外的都说：“晚上回答你，现在在撸代码。”用“撸串”中的那个“撸”来形容代码，从字面就可以感受到那股欢快劲。当然，我们也可以想象出，那个时候或许他正干劲十足地死磕某个技术问题。
技术之外，笔者也翻出其中有一位客户写给汪建明的夸奖邮件：
“今天如果没有你的帮助，我们的RDS可能会出现更加严重的问题。风移同学接手后，迅速找到了问题发生的原因。在半个小时之内，不但提出了解决方案，还帮我们完成了大部分的调优工作，及时阻止了问题向更加严重方向发展。调优完成后，他还持续观察了很长一段时间，确保问题得到了解决。他又将处理步骤和思路发邮件给我们，并通过电话给我们详细讲解。交流过程中，我们的同学也向风移同学咨询了一些日常工作的疑惑，他也不厌其烦的为我们的同学一一解答。无论从技术的专业程度和工作敬业程度上风移同学都是无可挑剔的。”
从上段表扬信，我们不难看出，他是如何践行客户第一——那是真的全身心投入，解决客户的每一个小问题，急客户之急，想客户之想。像他这样，客户怎么会不放心，怎么会不感动，怎么会不成为阿里云的忠实Fans，并用他们自己的行动来为阿里云站台。
不论是技术，还是服务上，汪建明都无一彰显着四个字——知行合一。知行合一，是天底下最容易，也是最难的事。而这点，你能做到吗？（本期接受访谈的云栖专家/
风移；文/我是主题曲哥哥）
- 《沉淀》第十三期：【[沉淀]访谈阿里孙伟光：多行善事莫问前程的他，将计算集群的CPU利用率从30%提升到70%+】做事情不能单单盯着KPI，不是KPI的事情不做。
- 《沉淀》第十二期：【[沉淀]从网络中间件到搜索，从移动开发到分布式计算平台，阿里高级专家李睿博谈自己的折腾路】整个过程我觉得还是爱最重要。有爱才有勇气才有希望。我是真的爱写代码。从小学就开始爱，到现在快三十年了也还爱。
- 《沉淀》第十一期：【[沉淀]阿里高级专家应答：各种数据在一个统一计算平台上的融合，才能产生更大的价值】阿里巴巴这种超大数据体量上才会遇到的独特挑战，让应答在技术上有了更清晰的认识，一定要夯实分布式系统的基础。“只有把基础夯实了，才能支持上层各种计算场景在大体量上的实现，让各种新的算法在‘阿里体量’上真正发挥潜力。”
