技术

近程视频一对一领导：论文、调研报告语句优化计算机常见工具、技术Linux常用命令（python）模仿数据生成ACM高级题目

1 资损防控介绍得物提供大量商品交易等服务，资金流转量大，任何因为设计缺点、零碎缺点、系统故障、人为操作、安全漏洞等因素都会引发间接或间接资金损失。资损防控就是在我的项目全生命周期内，引入多种资金剖析和管制伎俩，预防资损故障或管制资损故障影响范畴。 那么在日常工作中，具体如何发展呢？次要能够从以下三个方面来做： 1.1机制流程建设在业务我的项目开始时，咱们应该评定我的项目资金危险等级，比方高风险须要重点关注&投入，中危险须要投入多少资源，低危险又如何保障。 在我的项目资金危险评定后，产品架构设计时须要包含技术危险设计，比方幂等、分布式数据一致性、异地多活等。 而后对于高资金危险我的项目，咱们须要出专门的资金危险系分，在得物重点关注资金流、信息流以及物流的流转，比方业务的高保链路是怎么样的，有哪些资损危险点等。 接下来就是对输入的资损危险点进行布防，布防的模式次要是核查和监控，核查为主，监控作为兜底，因为后面输入的资损危险点可能会有脱漏，监控是业务异样的感知伎俩。日常咱们也能够通过混沌工程进行危险开掘&核查规定验证。 最初咱们需对资损危险告警进行应急，拉起应急小组排查确认危险并修复。 1.2人员阵型建设资损防控并不是靠某一个角色来承当，而是须要架构、研发、品质和SRE一起来防控并嵌入日常工作流程中，从组织架构视角，咱们须要建设至多三道防线，即研发防线，品质防线和SRE防线，互相兜底，合并共举达到资损防控的目标。当然各角色在我的项目各个阶段各有偏重，比方SRE负责业务线上稳定性，那么线上的资损防控投入绝对大一些。 1.3多体系防控从发现资损危险时效视角来说，能够分为实时核查（T+0）、近实时核查（T+M）、离线核查(T+H, T+1)，每种核查形式都有其适配的业务场景，并不存在代替之说，比方不落库的配置变更实用实时核查，业务定时工作实用离线核查等等。理论业务场景布防时需剖析业务特点，而后再应用适合的核查体系工具。在组织分工方面，研发偏重离线核查，测试偏重近实时核查，SRE偏重实时核查，当然理论工作中并不用这么界限明显，本人看到的危险点，能够选用适合的工具体系。 从核查是否影响业务运行视角看，能够分为旁路核查和主路核查，旁路核查的后果对业务运行不形成影响，仅仅是危险揭示，而主路核查是有能力影响业务运行的，比方资损熔断用的就是主路核查技术，在核查告警报出后中断业务运行。目前公司已有的A、B平台都属于旁路核查体系。 在布防核查规定后，咱们怎么测验布防的有效性，同时因为业务迭代倒退，早前布防的核查规定须要调整核查逻辑来适配新的业务逻辑，也就是说咱们如何保鲜核查规定？这就须要混沌工程资损演练来撑持了。资损演练又分为有损演练和无损演练，比方在线上搞有损演练时常常把金额数据加/减0.01，测验布防的核查规定是否发现，这样即便产生了理论资损也在演练估算能够笼罩的范畴内，但在线上搞有损演练需谨慎评估影响范畴。资损防控无损演练关键在于生产库的克隆，这样在演练时做数据篡改并不影响线上业务运行。 2 资损防控技术体系咱们在做资损防控时，最重要的一步是危险辨认，它是资损核查布防的源头，能够这么说，如果没有危险辨认就没有接下来核查布防。危险辨认能够通过人工剖析和智能零碎推导两种形式失去，从建设倒退阶段来说，人工剖析通常是最开始采纳的形式，在这个根底上，再通过算法推导+专家教训倒退出智能零碎推导。上面依人工剖析视角来开展，这里举例一个简化版得物零碎的资损防控如何做。如下图所示，右边为商品交易业务链路，其中包含用户下单交易和经营配置商品：因为交易平台落有订单交易的金额和状态，而汇金平台对接各领取渠道，是领取的理论执行者，这里就存在上下游订单金额、状态的一致性危险。 如用户购买的商品在加入营销流动，交易平台会查问商品经营平台具体流动逻辑，比方营销流动的估算、优惠券应用的限次逻辑，这里可能存在流动估算、优惠券应用的业务型危险。 经营人员配置某次营销流动，在圈品、价格等要害参数上呈现错配、漏配等配置型危险。 下面所说的危险通常须要在剖析PRD、技术实现文档或代码CR后能力辨认进去，接下来看看咱们如何进行布防。 2.1 T+1/T+H核查在整个资金防控体系的演进过程中，离线核查应该说是业界最先倒退进去的核查伎俩，最后与很多银行一样，是靠人力做以后的金额跟全天总账的对账，之后通过主动的形式，将全量数据库表导出后做计算来进行核查。目前在得物次要是通过ODPS来实现T+1、T+H离线核查，它的劣势是不影响业务生产库，并且因为是定时调度运行，所以对于业务定时工作等需较长时间数据回溯的场景比拟适配。 2.2 T+M核查通过数据库Binlog能够实现分钟级的资损核查，这种核查形式对于业务上下游一致性危险有十分好的发现能力，日常配合混沌工程的无损演练能力，对于未笼罩到资损危险也能够很好的揭示进去，所以T+M核查实用于涉数据库字段的一致性危险、盖帽等业务场景。 2.3 T+0核查随着业务的倒退，对于资损核查也提出更高要求，咱们须要倒退出实时核查能力。比方能够通过业务插桩的形式来实现同步/异步触发，同时实时监听业务执行音讯，而后数据路由至具体业务域执行核查逻辑，这种核查形式属资损防控畛域的重武器，实用于业务型危险、配置型危险，同时满足简单业务核查场景。目前SRE曾经在建设T+0实时核查零碎。 2.4 资损演练资损演练能够验证布防的核查规定有效性，又能够用来开掘未笼罩到资损危险，所以资损演练是资损防控体系很重要的一环。资金无损演练有以下三个关键点： 资损防控落地的规定都是针对业务数据来执行的 资损防控无损演练的数据来自生产环境 无损演练数据与生产环境数据本质是隔离的 下图为初步的资金无损演练计划： 3 得物业务实际作为反对得物业务的SRE主导了得物履约资金平安保障工作，因为得物履约的业务链路长，危险敞口大，咱们认真思考了业务稳定性及其资损危险并实际了前述的相干资损防控理念。 3.1 高保链路梳理出价、下单、领取、发货、结算、营销、逆向7个业务域定义出高保业务链路，输入资损点、变更点、新增表及字段以及相干监控点。 3.2 工具选型依靠现有工具平台进行布防，老本最优解。 3.3 规定布防资损防控通过核查规定落地，同时业务监控配置告警规定，通过混沌工程演练验证规定有效性。 3.4 观测告警a. 应急响应 b. 主动巡检 i. 每天主动巡检重要指标推送到对应的工作群 3.5 演练a. 对相干规定进行保鲜 b. 未裸露危险开掘 3.6 实时核查体系建设a. 业务插桩先旁路核查，后可阻断核查。 4 总结&瞻望在得物落地资损防控期间，作为SRE始终在宣导的理念：资损防控须要研发、测试、SRE三方相互协作，三道防线互相兜底，合并共举达到资损防控的指标。将来，资损防控咱们重点关注以下3个方面： 危险剖析--目前咱们次要还是基于专家教训，后续咱们将通过数据染色，血统剖析，做到自动化的危险输入。 多体系防控--欠缺资损防控体系建设，形象通用防控能力与可扩大的精细化防控能力，做到核查工具体系与业务场景相适配。 资损演练--在大规模的业务体系之下，纯靠人去做攻打，其实是不太事实的，必须得靠智能化、数据化的形式去驱动。同一个故障，咱们让它在成千盈百个零碎下面去重放，这样咱们就能够十分高效地去实现大规模危险的开掘，验证危险防控规定的有效性以及已布防规定的保鲜。 *文 / Yuerong 本文属得物技术原创，更多精彩文章请看：得物技术官网 未经得物技术许可严禁转载，否则依法追究法律责任！

（点击图片购买《社交泛娱乐出海作战地图》） 6 月 15 日-16 日，扬帆出海“第三届产品与增长大会（PAGC）”在广州 · 广交会展馆召开，融云携一站式全生态出海解决方案参会，与上百展商、7000+ 海内外业界精英一起，“谋变新格局、共塑新标杆”。关注【融云寰球互联网通信云】理解更多 年度重磅奖项“金帆奖”获奖名单也在大会正式颁布，融云荣膺「年度优良出海产品技术服务」奖，这是融云在 PAGC 年度金帆奖开办以来间断三年摘得该类目桂冠。 寰球大网性能持重 通信服务与时俱进来到国内的基础设施环境，出海企业在生疏的海内市场不免碰到难以解决的痛点、坑点。而融云等出海技术服务的撑持和助力，推动和见证着中国出海企业在寰球的生根发芽、遍地开花。 作为业余、简略、稳固的寰球互联网通信云服务商，融云外围团队源自飞信，团队已聚焦通信行业 18 年之久。开办以来，融云一直开释其 IM 一哥的行业影响力，间断 8 年稳居市场第一。 在服务架构上，以寰球通信网为地基，融云搭建了 IM+RTC 双核心通信能力，并贴近客户业务，笼罩社交泛娱乐、游戏、电商、出行等场景，推出“IM+RTC+X”一站式全生态出海解决方案。 迄今为止，融云曾经服务寰球 30 万+ App， SDK 触达用户数超过 80 亿。也就是说，均匀每个中国网民手机上都有 5 款以上的 App 应用了融云业务。 在服务性能上，融云日音讯峰值曾经超过 2218 亿，寰球范畴内端到端提早＜100ms，适配寰球机型＞3000 款，SDK 解体率＜0.01%，与挪动利用均匀解体率 0.29% 的行业标准拉开了指数级差别。 今年初，融云寰球通信网降级到了第四代，减少了更多服务链路和边缘节点，其寰球 P99 提早升高了 30%，在海内新兴市场的网络受限地区也有更好体现。 在中东等网络环境简单的地区，全新通信网从 DNS 发现、通信协议抉择、落点探测等方面做整体智能调度和客户端接入，保障链路不仅连得快，而且连得稳。 同时，融云也在继续致力于改善用户的本地化体验，在推送策略、加密技术等产品设计上晋升细节体验感，实现效率晋升和体验降级双进化。 底层服务性能持重、本地能力与时俱进，融云可撑持 App 在出海状况上来做各种新场景的摸索，包含 AIGC。 融云行将推出“集成便捷、开箱即用、简略可经营”的 AIGC 解决方案，把 IM 即时通讯、RTC 实时音视频通信与 AIGC 联合，让通信零碎不便地嵌入到 AIGC 的获取和生成流程中，并且可反对其高效晋升生成品质。 深刻腹地认知晋升 出海攻略全面降级融云从 7 年前开始进军寰球市场，在重点地区积攒了丰盛的服务教训，对出海重点市场、外围赛道有粗浅的认知，在很多地区都积淀出了实用当地的本地化计划。 ...

编者按：本文具体介绍蚂蚁平安科技应用龙蜥社区技术进行镜像减速的实际过程，能够让您理解如何基于龙蜥社区推出的容器镜像，Nydus 与 Dragonfly 镜像减速技术和 LifseaOS 为容器的启动减速。文章转自金融级分布式架构，以下为全文。 文/蚂蚁团体 ZOLOZ 团队01 背景简介ZOLOZ[1]是龙蜥社区理事单位蚂蚁团体旗下的寰球平安风控平台，通过业内当先的生物辨认、大数据分析和人工智能技术，为用户和机构提供平安又便捷的平安风控解决方案。ZOLOZ 已为中国、印尼、马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的平安风控技术支持。目前，曾经笼罩金融、保险、证券、信贷、电信、公众服务等畛域，累计服务用户超 12 亿。 随着 Kubernetes 和云原生的大暴发，ZOLOZ 利用开始在私有云上进行大规模容器化部署。ZOLOZ 业务的镜像通过长期保护和更新，无论是镜像层数还是整体大小都达到了一个较大的量级（数百 MB 或者几个 GB）。特地是 ZOLOZ AI 算法推理利用的根底镜像大小要远大于个别利用镜像（Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有约 234MB），对于容器冷启动，即在本地无镜像的状况下，须要先从 Registry 下载镜像能力创立容器，在生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥挤而无奈疾速地下载镜像，如此宏大的镜像给利用的更新和扩容等操作都带来了不少挑战。在私有云上容器化继续推动的当下，ZOLOZ 利用次要遇到了三大挑战： 算法镜像大，推送到云上镜像仓库耗时长，开发过程中，在应用测试环境进行测试时，往往心愿疾速迭代，疾速验证，然而每次改完一个分支公布验证都要通过几十分钟，开发效率非常低下。拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务失常运行。集群机器拉起工夫长，难以满足流量突增时，弹性主动扩缩容。尽管也尝试过各种折中的解决方案，但这些计划都有缺点，咱们当初联合蚂蚁、阿里云、字节跳动等多个技术团队打造了一套更通用的私有云上解决方案，该计划革新成本低，性能好，其中大部分技术都在龙蜥社区中发动、倒退、开源，目前看来是比拟现实的计划。 02 术语及定义OCI：Open Container Initiative，凋谢容器打算是一个 Linux 基金会我的项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化（最重要的是 Linux 容器）设计凋谢规范。 OCI Manifest：遵循 OCI Image Spec 的制品。 BuildKit：是 Docker 公司出品的一款更高效、Docekrfile 无关、更符合云原生利用的新一代 Docker 构建工具。 ...

达坦科技专一于打造新一代开源跨云存储平台DatenLord，致力于解决多云架构、多数据中心场景下异构存储、数据对立治理需要等问题，以满足不同行业客户对海量数据跨云、跨数据中心高性能拜访的需要。喷泉码具备极高的纠错能力，且具备低提早、地复杂度、高效率等长处，使其在冷存储、分布式存储、无线通信等畛域失去广泛应用。达坦科技致力于软硬件交融的解决方案，喷泉码的高效实现在硬件上，作为公司长期的技术储备，在本周的前沿科技分享中，达坦科技的联结创始人兼CTO施继成将为大家分享聊聊 RaptorQ 纠错码 。 1、演讲题目聊聊 RaptorQ 纠错码 2、演讲工夫2023年3月12日上午10:30 3、演讲人施继成 达坦科技联结创始人兼CTO  4、引言对于生产环境中的存储系统而言存储数据的失落是不可承受的，大家解决该问题的办法广泛有以下两种办法——多备份和冗余纠错码。本次分享就聊一聊近些年被宽泛应用的 RaptorQ 纠错码，该纠错码属于喷泉码，分享人将会对 RaptorQ 的背景，算法和利用等角度进行探讨。 5、内容简介本次演讲次要蕴含下列内容： 纠错码介绍。喷泉码介绍。RaptorQ 编码介绍和剖析。RaptorQ 应用场景和办法介绍。6、直播预约欢迎您预约直播，或者登陆腾讯会议观看直播：会议号：955-6910-3992

文/许庆伟：龙蜥社区 eBPF 技术摸索 SIG 组 Maintainer 高级内核技术专家，对 Linux 内核、零碎稳定性畛域有深入研究。 01 启示录新约圣经启示录认为：恶魔其实自身是天使，但炽天使长路西法背离了地狱，翅膀变成了彩色，坠落天堂，腐化成为恶魔。这些恶魔主宰着光明权势，妨碍人类与上帝沟通，无所不用其极。所以能够说天使和恶魔原本是一体的，只是命运不同。 随着 eBPF 技术在各种行业畛域上的应用和遍及，人们在享受着技术改革红利的同时，也蒙受着无孔不入的歹意攻打，就像任何事物都有两面性一样。没有任何一项技术只有居高临下的劣势，而没有弊病，只有更加清晰的刨析分明 eBPF 的内核，能力推动它一直的提高，趋利避害，尽可能施展正向的作用。 那么，eBPF 是天使，亦或恶魔？ 越来越严厉的 Linux 安全形势依据平安剖析机构 ESG 云原生平安钻研（链接见文末），88% 的网络安全专业人士示意，在过来 12 个月中，他们的云原生应用程序和基础设施蒙受过攻打 。然而，许多旨在爱护 Linux 的云平安解决方案可能很麻烦且具备破坏性，因为它们是从 Mac 或 Windows 操作系统上移植而来，这些计划有时会影响到 Linux 零碎的解决能力，甚至进行更改。 在 Linux 畛域，很多平安公司都公布了自研的 MDR、XDR、EDR 产品，大多数计划是基于轻量级代理在静默收集遥测数据，同时最大限度地缩小任何可能的性能影响，并将托管检测和响应扩大到零碎的本地和云上，通常构建有基于规定的主动响应和剖析性能，比方 SanerNow、Automox、Cybereason、Syxsense Secure、Sangfor Endpoint Secure 等等，大抵有以下特点： 从端点监督和收集可能暗示威逼的流动数据评估收集的数据以确定威逼模式主动响应已辨认的威逼以打消或遏制它们，并告诉平安人员应用取证和剖析工具钻研已辨认的威逼并寻找可疑流动目前在 Linux 环境下，对于 EDR、XDR 产品也提出更加严格的要求： Linux 威逼和攻打媒介与 Windows/Mac OS 对应物不同，须要独自构建策略。Linux 通常是生产零碎的根底，不能因为产品的中断或烦扰会对业务产生负面影响。构建轻型 Linux EDR 传感器专为 Linux 构建和优化，对系统的影响降到最小。 基于 Linux 零碎的云原生基础架构设施云原生应用程序的组合是 CI/CD 继续集成和交付的 API、容器、VM 和无服务器性能的组合。爱护这些应用程序、底层基础设施和协调其部署的自动化平台，须要从新扫视威逼模型、取得组织一致性并利用有目标的管制。此外，随着安全性和 DevOps 一直交融，云安全控制正在失去整合。将孤立的办法倒退为对立的策略，以爱护云原生应用程序和平台是目前很多平安厂商发力的指标，也是甲方实实在在的需要。与此同时，更多的平安厂商正在尝试将云平安态势治理 (CSPM)、云工作负载爱护 (CWP)、容器平安等计划，整合到集成的云平安套件中，从而增大本身平安产品在市场上的竞争力和话语权，也防止平安产品的碎片化。 ...

龙蜥大讲堂是龙蜥推出的系列技术直播流动，邀请龙蜥社区的开发者们分享围绕龙蜥技术开展，包含但不限于内核、编译器、秘密计算、容器、贮存等相干技术畛域。欢送社区开发者们积极参与，共享技术盛宴。 往期回顾龙蜥社区技术系列直播截至目前已举办 61 场直播流动，通过钉钉、视频号、B 站平台进行直播，邀请了来自 Arm、阿里云、Intel、浪潮信息、挪动、联通、普华根底软件、海光、统信软件、龙芯、飞腾、中科方德、鉴释等公司的开发者进行技术分享。 龙蜥大讲堂笼罩了今日头条、B 站、InfoQ 、CSDN、 51CTO 等多媒体矩阵，吸引了泛滥开发者和技术爱好者观看，在 51CTO、InfoQ 等媒体渠道播放量均达 2000+，其中镜像集群 SIG 分享视频在流传矩阵中播放量包揽 TOP 5。 焕新启航过来，「龙蜥大讲堂」为大家带来了泛滥高质量多畛域的技术演讲。新年伊始，为了让各位开发者和技术爱好者有更极致的、沉迷式的观看体验，对龙蜥技术有零碎且全面的理解，自 2023 年 2 月开始，「龙蜥大讲堂」实现全新改版，以月度主题模式发展当月分享。 如 2 月分享主题为 SysOM 一站式零碎迁徙运维平台。让咱们整个二月一起徜徉在 SysOM 的陆地中吧~ 留神：在当月中上旬更新下一月度的演讲主题，并推送至社区官网，请各位感兴趣的技术同学及时关注并报名。 嘉宾招募3 月分享主题方向——秘密计算，比方海光 CSV、AMD SEV、Intel TDX、Intel SGX 等，欢送小伙伴们报名分享。 报名链接：https://openanolis.mikecrm.co... 若有任何疑难，欢送增加龙蜥助手-小龙微信【openanolis_assis】征询，龙蜥大讲堂详细资料关注龙蜥公众号【OpenAnolis龙蜥】，回复关键字“操作指南”即可获取。 往期全副材料课件地址：关注微信公众号（OpenAnolis），回复“龙蜥课件” 即可获取。视频回放：https://openanolis.cn/video/下期直播预报明天（2023.2.13），社区邀请了零碎运维 SIG Contributor 李晔分享《龙蜥自动化运维平台 SysOM 2.0 的操作系统迁徙性能介绍》，带大家持续理解 SysOM 2.0 中操作系统迁徙的功能设计，操作方法和问题排查等。快来扫描下面海报二维码入群，预约前排小板凳观看直播！

三天研发，两天设计；01【优先做设计方案】 职场中的那些魔幻操作，研发最烦的是哪个？ 作为一个数年且资深的互联网一般开发，能够来阐明一下为什么是：不足设计； 面对业务需要的时候，可能都听过这样一句话： 这个很简略，间接开发，三天内上线； 产品听了流泪，测试见了解体，研发眉头一皱直呼什么鬼； 如果没有听过，那么职场的经验可能是不完满的，然而侥幸爆棚； 这种魔幻般的神奇操作，逻辑在哪里？底线在哪里？唯独离谱在这里； 从实践经验上来看，产品研发抛开业务设计所带来的反伤，兴许会早退，但相对不会缺席； 所谓的简略业务流程，仓促上线之后，后续补坑的老本可能高的离谱； 绝对于残缺的研发周期来说，设计、落地、一次性的高质量实现，就是老本最低，效率最高的决策； 对于研发角色，方案设计通常就是围绕技术和业务两个外围； 02【罕用的方法论总结】 在做方案设计时，必然要使用一些根底的形式办法； 无关办法的经验总结很多，然而真正罕用的并不多，以下只围绕集体在工作中罕用的几个来剖析； 实质：了解实质的时候，必须明确在肯定的空间和工夫范畴内，须要有边界束缚； 如果范畴扩充，思考的因素太多，相互间的影响和关联适度简单，脱离实际太远，很难得出合乎现状的论断； 在工作中时常会说：透过景象看实质，了解不同事物的共性和共性，判断倒退逻辑； 那么，如何了解产品研发的实质？ 基于业务的供需关系，继续打造优质的产品服务； 这个形容只是集体的实际领会，对于事物的实质了解，应该简单明了，直击核心内容； 矛盾矛盾是指事物外部以及事物之间的对立统一关系，尽管概念很形象，但景象简直是无处不在； 用艰深的形式来了解，就是需要和利益之间的抵触且对立的关系； 以常见的平台商业模式来思考； 平台方：心愿以低成本的服务获取更高的营收； 客户方：心愿以低成本取得更好更优质的服务； 平台与客户单方，都心愿低成本付出，获取更高的回报，矛盾就这样产生了； 然而，平台失去客户，没有继续生存的能力；客户自身又依赖平台服务，关系既对立又存在抵触； 单方的单干，随着不同阶段的外围问题被解决，即事物的一直倒退变动，新的问题和矛盾也会呈现； 零碎了解事物的全貌，横向扩大的广度，纵向倒退的深度，在工夫空间的变动中，以动静的思维应答事物的变动； 简略的说就是：全面的看事物，零碎的解决问题； 以理论的研发案例来剖析； 面对并发业务的简单流程时，比拟经典的就是抢单场景，解决的思路有很多种； 如果资源足够，间接扩大以撑持申请解决； 如果资源有余，能够限度申请端的放行比例，服务端只解决大量申请； 或者服务端对申请异步解耦，疾速失败掉大量的申请； 所以在面对问题时，不用只全面的看一个方向，围绕问题的矛盾多方，兼顾寻找均衡的解决办法； 周期在周期景象中，存在事物的倒退和演变法则； 即事物在静止、变动的倒退过程中，某些特色多次重复呈现； 比拟经典的景象就是业务的倒退周期：孵化期、验证期、成长期、成熟期、衰退期、转型或者沦亡期； 了解事物的倒退周期，能够在不同的阶段把握外围事项，解决关键问题； 分治分而治之是研发的外围能力之一，强调对复杂事物的拆解能力； 随着技术水平的成长，面对的业务问题也更加简单，必须具备拆分能力，分而治之； 流程的分段治理；技术与业务的拆散；代码工程的分层保护；零碎的分布式架构； 这些都是研发过程中罕用的分治伎俩； 面对诸多的方法论，首先围绕几个根底办法进行思考和实际，从而了解其外延和精华； 而后，再借鉴其余的办法，造成本人的办法体系； 基于一些外围的方法论之上，再去思考业务和技术的设计，在思路上就会成熟很多； 03【如何剖析业务】 想要剖析业务，首先要粗浅的了解和洞察业务整体； 在集体习惯上会考量三个档次：首先了解业务全貌，其次了解负责的业务板块，最初了解具体的业务需要； 了解业务全貌了解业务全貌，实质就是明确公司在做什么，组织架构的合作流程，团队的工作方向； 业务的惯例定义：行业的基本模式，运作的流程，具体的事务执行； 在理论的工作中，职级越高越是须要具备对业务全貌的剖析能力； 行业剖析并非一般玩家所能了解的，须要极其顶级的思维和常识储备，以及对各个信息的兼顾剖析； 作为研发来说； 应该了解业务的投入和营收，并且能意识到这种模式是映射到产品设计或者服务中的； 必须了解业务模式所对应的产品矩阵设计，各个外围性能的流程和门路； 了解负责的业务板块集体的工作习惯，并不是惯例的流程机制； 明确本人负责的业务板块，把握工作重心，不同阶段中调整能力的输出（学习）和输入（生产价值）策略； 产品矩阵的设计与业务模式有间接关系，也是梳理本人工作板块的外围根据； 对于产品来说，常见的拆分有两种； 例如以端口为根据划分的C端和B端，以零碎为根据划分的业务利用和数据利用； 对于业务来说，拆分的模式则更加灵便； 在经营概念上可能有多个业务线，然而对于研发来说，各种业务线之间存在诸多的流程交互； 对于集体来说，能够从业务、技术、数据三个根底的方向梳理，或者依据具体的经营模式梳理； 了解业务全貌和集体的负责板块，以此明确工作重心和方向； ...

1 月 13 日，龙蜥社区别离召开了第 10 次技术委员会会议和第 14 次经营委员会会议，来自 21 家理事单位的委员代表缺席。两个会上别离总结和回顾了龙蜥社区 2022 年度整体技术和经营倒退状况，就社区产品、重要技术决策、社区治理、2023 年度经营打算、龙蜥社区重要流动等进行了同步和研究。本次会议，技术委员会会议缺席 30 人，由 Intel 金运通主持；经营委员会会议缺席 26 人，由浪潮信息张旭芳主持。 01 第 10 次技术委员会会议 会议开始，技术委员会主席杨勇就 2022 年社区倒退做了发言，他说到：“2022 年社区倒退降级，更加重视社区合作，明确了 8 大技术方向，保障社区技术倒退方向的当先性。社区产品建设继续提高，包含下一代操作系统 Anolis 23 和云原生套件公布、龙蜥 3 大操作系统产品系列、9 大次要上游衍生版，基于龙蜥的操作系统和云原生端到端解决方案等。社区基础设施 ABS 构建零碎、T-One 测试平台、CI/CD 进一步优化改良，为社区更高效顺畅合作提供保障。社区客户服务多样性、利用场景诉求丰富性极大加强。所以咱们有信念社区能够放弃可继续向前倒退。” 接着技术委员会副主席孟杰为整体委员同步了 2022 年龙蜥社区整体技术倒退状况。能够看到，龙蜥社区每月都有重要的代表性成绩和提高，如 Anolis 23、Anolis 8.6 版本、RISC-V 版本公布等等。会上，云原生 SIG（Special Interest Group） 报告了 ACNS 研发路标和打算，目前 ACNS 和 Anolis OS 独特造成全栈的云原生解决方案，通过与理事单位的合作开发，曾经服务了爱奇艺、好雨科技等泛滥社区合作伙伴。在圆桌探讨环节，整体技术委员对 RISC-V 反对状况、Rust 生态的前瞻性思考布局、国密（商密）算法生态赋能、Anolis 23、Anolis 25 发行版的反对打算等开展深度探讨，其中： RISC-V ARCH SIG 反对状况，目前龙蜥社区曾经公布了 RISC-V 反对，来自平头哥、中科院软件所、统信软件等都为 Anolis OS 的 RISC-V 架构反对做出了奉献。后续 RISC-V SIG 持续踊跃推动社区更广度深度的单干，凝听来自各合作伙伴的诉求倡议，近期也会组织 RISC-V SIG 做系统性汇报工作。 ...

2023年 1 月 4 日，中国技术先锋年度评比 | 2022 中国技术品牌影响力企业榜单正式公布，网易有道凭借科技翻新实力入选榜单30 强之列。 “2022 中国技术先锋年度榜单”由中国当先的新一代开发者社区 SegmentFault 思否公布，旨在推动科技企业进一步晋升技术品牌声量，减速企业生态建设。榜单依靠社区内数百万开发者用户数据分析、各科技企业在国内技术畛域的行为及影响力指标，最终评比出 30 家上榜企业。作为中国当先的智能学习公司，网易有道基于自研的 AI 核心技术，联合对学习场景的深刻理解，打造了一系列深受用户喜爱的学习产品和服务，现已开辟硬件、课程、教育信息化等多元业务，包含网易有道词典、有道词典笔、有道AI学习机等智能学习工具，致力帮忙用户实现高效学习。新的一年，网易有道将继续加强科技生态建设，服务宽广开发者，以当先技术打造更多高质量科技产品，放弃高质量技术内容输入，和开发者独特成长。 附：《2022 中国技术品牌影响力企业》图：榜单长图

1、演讲题目RDMA网络拥塞治理架构 2、演讲工夫2022年11月27日上午10:30 3、演讲人张乙然  北京邮电大学网络与替换国家重点实验室、计算机学院，副研究员、博导  4、引言RDMA网络目前成为数据中心、存储、高性能计算等畛域的要害基础设施。在本次分享中，我将介绍自己在RDMA网络拥塞治理架构方面的最新学术研究（SIGCOMM’21: Congestion Detection in Lossless Networks）。 5、内容简介报告内容从拥塞治理架构的基石—拥塞探测问题登程，针对RDMA网络中逐跳流量管制对拥塞探测的影响，重新认识并定义了无失落RDMA网络交换机端口的三元状态。翻新地提出了三元拥塞探测，为拥塞控制算法提供更精准状态信息，加强已有算法的决策，激发基于三元状态的拥塞治理钻研的全新摸索。 6、直播预约欢迎您预约直播，或者登陆腾讯会议观看直播会议号：581-8301-3525

你或者在我的项目中遇到过这样的状况。成员A成员B都用得上一个后端接口api，但它们相互不晓得对方什么时候申请这个接口，因而导致一关上页面，同一个接口居然反复申请了屡次。因为用户手抖，又因为成员遗记做申请的loading防误触解决，导致一个接口被用于疯狂申请，最终数据乱套，页面不可用。SPA单页面利用，多个页面甚至是多个组件可能有同样的数据申请，齐全能够共享的数据却不得不反复申请，影响页面加载效率。想要用节流或者防抖解决下面的问题，然而后端返回数据的工夫浮动太大，导致不晓得应该设置多长的工夫。这些申请节约，实际上都有调用异步函数（async function）的参加的；因而，它们虽不是async function的问题，但却能够利用async function的特点来解决。async function实质上是一个Promise。因而只有利用好Promise的个性，就能解决这些问题。once-init 正是为解决这些问题而生。它从 Promise 的定义登程，用 Promise 的根底性能彻底地阻止了异步申请节约的产生。我用它做了两件事：缓存申请的返回值；缓存Promise申请自身；原理once-init 的核心思想是缓存和执行队列；缓存返回值实现缓存返回值并不艰难，只有写一个单例模式就好了。上面是一个缓存的单例模式的简略示例；如果缓存曾经有值，返回缓存的值；如果缓存没有值，执行异步函数；执行结束后，更新缓存；这是一个繁难的解决方案，它大略能解决10%的异步函数相干的问题，因为在第一次执行Promise实现之后，就不会再进行申请，也就不会产生节约了；然而，它没有解决多个Promise同时产生的状况。假如开发人员同一时间屡次调用init，如果第一次调用的Promise还没有实现，cache也还没有初始化，就会导致同一时间的所有调用仍旧创立新的Promise。甚至有可能因为屡次申请，一直的变动cache，你甚至没有方法确定最初cache的值是不是你最初一次申请的返回值。如果要解决这个问题，就须要利用Promise的个性，同一时间，同一个async function，只容许同一个Promise处在pending状态。缓存 Promise如果Promise正在执行，就不创立新的Promise；间接返回正在执行的Promise的返回值；如果没有Promise正在执行，就创立并缓存新的Promise；Promise执行完结之后，删除缓存的Promise；通过这种形式，就能防止promise同一时间反复执行。这也是once-init这个库的核心思想。当然这个简略实现还有很多问题须要解决。通过这种形式，就能防止promise同一时间反复执行。这也是once-init这个库的核心思想。

文/ eBPF 技术摸索 SIG 随着 eBPF 技术的广泛应用，在操作系统层面提供了更多的观测能力，站在操作系统层面对利用的行为数据进行 trace 追踪成了一种利用监控的新伎俩，本文次要介绍基于 eBPF 实现对利用网络数据监控的背地逻辑。 一、一个申请数据包的组成一个残缺的利用申请数据包次要蕴含申请地址信息及具体的申请数据。其中申请地址信息就是咱们常说的五元组信息(IP+端口+协定)，这部分都是操作系统协定栈负责去解析；而申请数据则由利用通过各种协定去封装并解析，常见的利用协定有：http、mysql、rediis、dns 等。 利用每一个申请数据的承受与发送都是通过网络相干的零碎调用与操作系统交互，如果申请报文没有加密，那么在零碎调用处做一个拦挡通过函数入参就能轻而易举的拿到利用协定数据。当下热门的利用可观测都是基于此办法对利用网络数据进行trace，包含：时延、流量统计、协定等。 二、基于零碎调用的申请追踪2.1 网络申请模型一个利用过程基于零碎调用的网络申请模型如下(这里仅介绍客户端)： 通过 socket 去建设套接字，取得一个 fd 作为 socket 的标识。通过 connect 填写 IP 端口信息发动申请连贯。通过read/write申请/接管具体数据，除了read/write零碎调用还有send/recvfrom，readv/writev 等可用。通过 close 完结本次申请。 通过下面的流程图咱们大略理解了一次残缺网络申请的零碎调用逻辑。有几点须要留神： 对于单个建链实现的申请而言，其发送数据和接收数据往往是串行的，或者说一个 write 必然匹配一个 read，因而咱们能力统计到 RT 工夫，而 read/write 的返回字节数就能够作为咱们的流量统计。write/read 如何配对，对于客户端而言，是先 write 再 read，罕用的做法是通过过程 pid 和 socket fd 作为配对标识，实现 write/read 这一次残缺申请数据的配对。2.2 零碎调用追踪eBPF 技术能够在不扭转内核源码或加载内核模块状况下在内核插入指定 hook 代码，能在内核或应用程序执行到一个特定的 hook 点时执行。预约义的 hooks 蕴含零碎调用、 函数出/入口、内核追踪点、网络事件等等。 有了 eBPF 做零碎调用的 hook 当前，零碎调用的事件采集对于咱们来说变得分外不便，只不过咱们须要留神下哪些事件须要上报及申请数据上报当前的匹配策略。同时对于获取申请数据是有一些考究，对于 write 发送数据而言在零碎调用函数入口间接获取入参就能够获取数据，然而对于 read 读取数据而言咱们须要在零碎调用函数的进口做 hook 去拿数据。 ...

近日，ShowMeBug 发表将在 9 月 24 日线上线下同步举办 ShowMeBug2.0 新品发布会。据悉，ShowMeBug2.0 新品发布会以“ESSENCE 回归技术招聘实质”为主题，重磅公布 ShowMeBug2.0 新产品。 届时，ShowMeBug CEO 李亚飞将在发布会上进行演讲及演示产品。同时奇绩创坛创始人兼 CEO、前百度团体总裁兼首席运营官陆奇博士也将在线上用最前沿的视角瞻望科技公司将来倒退之路。 自创建以来，ShowMeBug 作为⾄简天成公司旗下一款数字化驱动的可记录、可剖析、可复盘的技术评估和在线 Coding 面试平台，利⽤创造性的实时互动代码协同技术和 WebRTC ⾳视频技术，还原实在的 IDE 编程环境，让用户体验硅谷风行的像真正工作中一样的代码面试。 而在本次发布会上，ShowMeBug 将会全新降级，从在线笔面试工具降级到一体化技术人才评估平台，用实在的编程环境，帮忙企业更精准地辨认真正能解决问题的工程师，降级企业技术人才队伍，从而在将来寰球竞争中取得更多劣势、谋求更大倒退。 ShowMeBug 已为 6000+ 大型和高成长型企业提供服务，包含互联网行业的 e 签宝；游戏行业的莉莉丝；半导体行业的沐曦、瀚博半导体；汽车行业的吉利等等。目前平台已承载超过 50 万场面试，用户口碑 NPS 评分超过 6.5 分，取得宽泛好评。 目前，ShowMeBug2.0 新品发布会线上直播曾经开启预约，公众可在 ShowMeBug 官网公众号（微信号：待设置）及微信视频号预约和观看直播。整场大会也将在 ShowMeBug 及 HRflag 微信视频号同步直播。

技术招聘很难，辨认人才不易身为 HR 的你却常常面临... 技术简历水太深图片，花了九牛二虎之力找来的简历，技术官却没一个称心的； 招进来的人明明面试时所有 OK，用人部门却反馈能力不行，还要从新招图片； 被老板追着说技术招聘的老本太高、效率还低，却始终找不到方法解决图片... 难道这所有当真无奈防止吗？技术招聘当真不能一步到位吗？ 锁定 “回归技术招聘实质”ShowMeBug 2.0 新品发布会 9 月 24 日 14:30全网直播 1 破局之道技术候选人简历，怎么筛才正当？如何技术评估，才是迷信形式？让技术招聘降本增效，怎么做才不费劲？ 发布会上，ShowMeBug CEO 李亚飞将现场揭秘：ShowMeBug 2.0，如何让技术招聘回归实质！ 通过标准化、自动化的评估流程代替传统技术面试，从技术招聘实质登程，让 HR 和技术官轻松搞定技术招聘。 2 重磅嘉宾将来科技公司的发展趋势是什么？ 奇绩创坛创始人兼 CEO 陆奇博士，曾任百度团体总裁兼首席运营官、微软寰球执行副总裁、雅虎执行副总裁。他将用最前沿的视角瞻望科技公司将来倒退之路！ 立刻扫码预约9 月 24 日（星期六）14:30 直播

2022 年，“裁员” 阴云持续洋溢。 近期，滴滴、阿里、百度、腾讯、贝壳、字节跳动、京东、有赞、小米、B 站、快手、58 同城、携程等都被曝裁员。如京东旗下京喜拼拼将优化 10-15% 人员；有赞教育板块的人员，微商城和批发的产研，中台技术裁撤 20%...... 被裁员收到 “毕业须知” 企业一旦呈现问题，晦气的永远是员工。 继 K12 风波、恒大 “爆雷”、海底捞敞开局部线下门店之后、阿里、腾讯大规模裁员之后、京东、有赞也大规模的裁员了！这个 2022 年，会让员工更加寒心了吗？ 后疫情时代下的待业 “寒冬” 裁员原本并不是什么特地稀奇的新闻，毕竟在一个企业中，优胜劣汰与业务线优化都是比拟常见的操作。 但京东、有赞这次，却让人倒吸一口凉气：有传言称：2022 年的裁员浪潮不会就此而止 ，实习生能够被随时 “就义”，大龄基层员工朝不保夕，管理者也无奈幸免！大型企业寸步难行，中小企业更是接受着微小的生存压力。某考察显示，中小企业有着更拮据的现金流：超六成企业仅能维持 1- 2 个月，能撑 6 个月的只有一成... 面对这样的状况，所有企业无一例外地均采取裁撤员工、暂缓扩招、缩减薪资等伎俩来进行自保。 而在这样的生存现状之下，作为打工人的咱们，天然就成为了企业们自救的 “殉道者”。待业寒冬悄悄而至！ “寒冬” 中的实力对决 面对重复横跳的疫情、夹缝中的企业，2022 年的待业模式将会愈发艰巨。 来自 CRMEB 不齐全统计数据显示，2022 届高校毕业人数已冲破 1000 万人，而由教育部推出的 “24365 智慧待业平台” 往年仅提供了 342 万条岗位信息... 艰巨的待业局势，也让许多学编程的同学因为刚毕业没有教训陷入了更被动的处境之中： 投出去的几十份简历杳无音讯... 公司动荡，随时面临着被优化... 降职之路遥遥无期，涨薪更是天方夜谭... 更有甚者，刚开始 hr 还笑脸相迎，一听没有开发教训刚毕业的，霎时投来厌弃的眼神... 在这一场 “寒冬” 之中，具备开发教训的人群将占有更大的平台和资源。 工作教训和实战经验，正越来越成为机会的敲门砖！ 除了一直修炼本人，让本身能力更好地匹配这些环境及政策变动之外，无论是想晋升退职场的竞争力，还是出于想进一步地往开发工程师等或者部门主管方面思考，晋升开发教训都成了事不宜迟。 近几年来，动手残缺的开源我的项目曾经是公认的事实～越来越多的人退出了钻研开源我的项目的大军之中！ 国内的开源我的项目虽多，但各种的档次不弃，有的局部开源，源码仅供学习。有的各种热门性能被阉割，营销模块走的是插件模式，插件须要付费能力应用，那这种的开源我的项目就不举荐大家钻研，老本太高，也不易老手学习。咱们要抉择全开源，根底功能齐全，文档也也齐全，能够收费商用的这种，咱们学习钻研明确这样的开源我的项目，在当前的工作中对本人会有很大的帮忙，因为当初大环境不好，很多的企业都开始也用开源我的项目给客户做二开来给企业降低成本，咱们对开源我的项目相熟，应聘的时候本人也有底气，参加开发的时候也能得心应手。 那么小编在这里给大家举荐一款全开源我的项目，这个零碎的好多功能都是别的付费版才有的性能，性能稳固、平安、功能强大，帮忙文档、二开文档齐全，还有收费技术交换群，真的是业界良心开源作者了！它就是码云排名前三的开源 GVP 我的项目 ——CRMEB 开源买通版 ...

2022年4月25日，凋谢原子开源基金会 OpenHarmony技术日在深圳隆重举办。本次大会以“共建新技术、开辟新畛域”为主题，聚焦OpenHarmony 3.1 Release版本，解读新版本个性，摸索行业时机、展示生态凋敝。为激励更多企业和集体参加到OpenHarmony生态共建与推广中来，公布了 OpenHarmony Ambassadors大使打算，Evangelist布道师打算、Contributor开源贡献者打算。面向深度参加OpenHarmony社区建设的开发者及共建单位成员、OpenHarmony我的项目贡献者，招募提拔大使、布道师和贡献者，以表彰他们推动OpenHarmony开源生态凋敝所作出的奉献，并进一步推动社区凋敝。OpenHarmony是由凋谢原子开源基金会(OpenAtom Foundation)孵化及经营的开源我的项目，指标是面向全场景、全连贯、全智能时代、基于开源的形式，搭建一个智能终端设备操作系统的框架和平台，促成万物互联产业的凋敝倒退。截止2022年4月，OpenHarmony已有2000+社区代码贡献者、160万社区用户、6300万下载次数，是目前中国最受企业和集体开发者欢送的开源我的项目之一。Ambassadors大使打算，Evangelist布道师打算、Contributor开源贡献者打算的推出，旨在推动OpenHarmony开源生态的遍及，减少会员单位成员在行业的技术影响力。 Ambassadors大使打算 Ambassadors大使打算针对OpenHarmony共建单位及OpenHarmony我的项目贡献者开展招募报名，打算8月份进入大使候选人资质评审，并于10月正式对外公布大使受权名单。OpenHarmony大使候选人需具备推广OpenHarmony的趣味、激情，违心帮忙别人理解OpenHarmony我的项目，并继续通过演讲、撰写技术文章、组织社区活动来推广OpenHarmony技术。 通过评审并最终成为OpenHarmony大使的成员将会取得OpenHarmony的官网背书以及丰富的资源反对，包含取得OpenHarmony Logo的受权，PMC/讲师资源反对、社交媒体的推广反对、以及取得OpenHarmony第一手信息和官网技术培训的资格。除此之外，OpenHarmony大使将取得充沛的集体品牌展现机会，包含取得在OpenHarmony网站的展现机会，媒体专访的机会，官网重要流动的参加和演讲机会，其文章或博客也将失去OpenHarmony官网媒体的流传加持，在多个维度继续打造集体行业技术影响力。 Evangelist布道师打算 Evangelist布道师打算针对社区对OpenHarmony我的项目感兴趣，且具备肯定技术背景的专家学者、社区KOL等，通过各类平台，跟大家分享和交换OpenHarmony最新技术、社区停顿等相干内容。认证后的布道师将在OpenHarmony社区官网公布，并颁发证书，同时也将流动专属技术支持，OpenHarmony新版本公布前取得提前的版本及专属培训、流动议题优先申报，帮助推广布道师的文章、观点。年初，将评比TOP3和TOP10最佳布道师，并针对最佳布道师开展集体品牌的推广流动。 Contributor开源贡献者打算 Contributor开源贡献者打算针对社区的开发者、被动在社区提交代码的高级开发者。将对Contributor开源贡献者颁发电子证书，对参加我的项目并且奉献微小的开发者，还将给予物质激励。此外，开源贡献者还将取得OpenHarmony大会VIP门票、各类OpenHarmony流动邀请等权利。获取Contributor开源贡献者社区身份的开发者，须要达成一些实质性奉献，包含pr合并；解决了某些issue，产生了优质代码奉献；Sig 组织经营奉献；Sig 组内奉献优质内容；利用场景示例我的项目奉献；残缺代码我的项目/代码demo奉献等任何一项。 OpenHarmony生态的凋敝离不开身处其中的每一位成员的参加和推广，作为OpenHarmony 工作委员会颁发给OpenHarmony推广者的一种荣誉认证，Ambassadors大使打算，Evangelist布道师打算、Contributor开源贡献者打算不仅是一份荣誉，更是一份责任，OpenHarmony开源的大旗，将由他们传递给越来越多的后来者。OpenHarmony开源生态的星星之火，必将在所有共建单位、成员的发光发热之下，出现燎原之势。也欢送更多优良企业、开发者参加到OpenHarmony的开发和实际中来，独特打造使能千行百业的泛终端数字底座。

在技术社区进行技术博客的写作，能让程序员有机会分享业余和集体教训、观点、见解和专业知识。它还使技术文章创作者建设本人的集体品牌，并与本人行业的同行、合作伙伴、客户和潜在客户进行互动。 技术社区中的博客文章涵盖了宽泛的主题，可能包含但不限于与大量程序开发主题相干的实践、策略和观点。在社区中撰写和公布博客文章时，请思考文章的主题是否与社区受众相干。它是否为博客的读者们解决了问题？ 以下是我这些年来技术写作生涯中的一些领会。 要有本人独特的格调你的读者们不光从浏览你的技术博客受害，同时读者们也能从你的写作格调里，对你有一个更粗浅的理解。有的技术写作者可能会钻研社区里一些浏览量高的技术文章的写作格调，而后试着去模拟。然而我集体认为，要让本人的博客在技术社区泛滥的文章中怀才不遇，最佳形式是领有本人独特的格调。 当然，你的技术写作如果目标仅仅是做本人的常识积攒，那么能够怎么难受怎么来。 利用正确的构造每一篇好的博客文章都应该遵循一个统一的探讨。 博客文章的结尾，应该包含对文章主题的介绍，一个涵盖内容要点的两头局部，以及一个蕴含所有内容的论断的结尾。确保每个段落都始终紧扣本人想要传播和与读者分享的指标。文章各段落的一致性越强，读者的体验就越好。 一个醒目的题目用一个醒目的博客文章题目吸引读者的注意力。确保题目乏味，可能吸引读者点击文章浏览。 目前国内社区有些技术文章的取名越来越像题目党聚拢，技术文章是否应该题目党，这是一个见仁见智的问题。笔者集体不会采取这种命名格调。 写一篇引人入胜的介绍既然曾经通过精心设计的题目吸引了读者的注意力，那么下一步就是为你的博客文章写一篇长篇累牍的开篇介绍，这让读者有趣味浏览更多内容，并为整篇文章中的精彩内容奠定根底。 提供精彩内容提供易于应用的有价值的内容。确保博客文章简洁明了，并分明地疏导读者沿着文章预期的门路后退。尽可能做到图文并茂，让读者的浏览体验变得轻松愉快，并提供好的解决方案或倡议。 在文章评论区踊跃与读者互动既然曾经花了大力量撰写并公布了博客并分享了本人的个人简介，记得通过回复读者在评论区对博客文章的留言来与读者互动。

申明：本文转自 DEV Community 网站，文章翻译由开发者社区提供；点击下方链接，查看英文原文： https://dev.to/aws-builders/s...在您加入过的会议中，是否曾有人解释软件系统是如何运行的？ 我已经和一个入行不久的解决方案架构师交换过，他试图向我形容他们设计进去的零碎：包含大概八个不同的组件，彼此之间以不同的形式互相通信。 在形容这个解决方案的过程中，他们不停地应用手势，以及大量的“这个部件通过......与那个部件进行通信”句式。 他们说的每一个单词我都晓得，但连起来之后我就搞不懂了。 在解释简单的概念架构时，语言就会失去意义。我正在遵循着一个思路搭建一个心理模型。我须要一个视觉展示模式。 我须要一个图表但不是一般的图表。架构图并不是一个万能的解决方案。 咱们最近探讨过，作为一名解决方案架构师，重要的一点是无效地将你的想法传播给技术和非技术受众。 你的图表必须思考到这一点。如果你想把想法传递给不同的人，你必须制作不同版本的图表。 咱们在这里要探讨的是，应该依据 5 种不同的受众，制作5种不同类型的图表。 咱们将以实在的 API，Gopher Holes Unlimited为例，在零碎中增加一个新的查问 gopher。 流程图流程图是最通用、影响最宽泛的图表。它是一个中高级的图表，蕴含工作流程的所有局部。 这张图展现了一个业务流程中的流动局部。 受众流程图的受众个别是技术型的。它能够用来向架构委员会论述构想，也能够向开发人员形容某个业务流程是如何运行的。 注意事项架构流程图次要由各个流动局部组成。在咱们的无服务器 AWS 环境中，咱们给每个托管的服务，以及哪些服务之间能够互相通信贴上标签。 咱们没有详细描述各局部之间如何相互作用，但展现了连贯状况，即显示出数据如何在零碎中流动。 服务图服务图从较高层级上展现了连接性。它不蕴含工作流或服务如何运行等细节，而是展现发挥作用的要害局部。下图展现了应用程序中应用的外部和内部服务。 受众IT 和网络工程师往往对这种类型的图表最感兴趣。他们关怀如何与内部服务进行连贯，另外，他们还想晓得是否须要对任何外部连贯进行监控。 我常常应用服务图向高管论述零碎的工作原理。他们想晓得次要应用程序之间是如何连贯的，没有什么比服务图更适宜出现这些连贯了。 注意事项搭建一个架构服务图时，最好列出所有组成应用程序或生态系统的微服务。表明哪些服务之间是互相通信的，并确保对外部服务和内部服务做出辨别。 在这类高层级图表中，无需具体阐明各个服务是如何运作的。所有使利用程序运行的服务都是如此。 角色图表明您的架构可能解决业务问题，这一点十分重要。角色图展现了一个按工夫顺序排列的视图，以及特定工作流中的不同角色。它是证实您在制订解决方案时将业务考量在内的最佳工具。 受众该类图表的指标受众包含以业务为导向的集体和产品所有者。他们关注角色，以及如何与零碎进行交互。这样一个展现“谁，在何时，做了什么”的图表，可能向受众完满地形容您的零碎。 注意事项角色图有点相似于 BPMN 模型，利用泳道来展现工作流中的不同角色。这类图表往往是低层级的，因为它蕴含更多的细节。要表明角色、工作流以及业务流程如何从一个步骤转到另一个步骤。 角色图也能够帮忙刚涉足某个畛域的开发者，为他们行将开发的货色提供丰盛的背景信息。 基础设施图基础设施图是一个“所见即所得”的模型。它代表所有曾经实现的货色。它在实质上是一个低层级的图表，包含服务/利用/生态系统中存在的所有。 基础设施图旨在展现曾经建设的货色和零碎以后的工作形式。能够把看做您构建的应用程序的蓝图。 受众基础设施图具备不同的受众。它能够用于向开发者展现在特定的微服务中须要解决的问题。也能够用于向客户展现您公司用于实现一项工作的全副资源。 技术人员是基础设施图的次要使用者。因为您提供的是一个清单，而不是展现想法或业务流程，所以此类图的预期应用范畴只限于信息。它是为那些喜爱“细枝末节”的人筹备的。 注意事项制作架构基础设施图时，不要脱漏任何局部。此类图表的指标是展现应用程序中的所有内容，以及它们是如何连贯的。您无需深刻理解所有的细节，而是要确保将应用程序中的所有局部都蕴含在图中。 开发者图在须要深刻理解状况时，开发者图是最佳抉择。它蕴含了开发者在构建解决方案时须要的所有。指标是解答任何在查看流程图时可能呈现的问题，并将其纳入设计中。这是最低层级的图表，旨在在您不在场的状况下传播您的想法。 应该有人可能读懂这张图，并分明地晓得该怎么做。 受众此类图的受众是施行解决方案的开发者。对于团队以外的人员来说，图表蕴含的细节水平是不必要的。有时候，对于不须要太多细节的受众来说，过多的细节可能是一件好事。 向开发团队以外的人员提供施行细节很好地阐明了细节太多并不是一件坏事。它会导致注意力的扩散，并覆盖您想要传播的其余信息。 注意事项开发者图实质上是增加了细节的流程图。标记出您能想到的任何一个具体的施行细节，还要标记出重要的过渡。 此类图表并不能取代用户故事，但它的确有助于强化用户故事，进步整个开发团队的了解程度。在能够应用开发者图的时候应用，因为在施行完结当前，您就领有了一个能够在将来参考的工具。 总结架构图有很多类型。每一种都有一个非凡的目标，为不同的受众服务。作为一名解决方案架构师，您必须可能在提出想法的同时，向正确的受众提供正确类型的图表。 在很多状况下，一个版本的图表是不够的。当我开始进行新的设计时，我总是从流程图动手。我会把我所有的想法写下来，而后获取其余解决方案架构师的认同。一旦咱们就解决方案达成统一，我就会把它变成角色图，而后拿给业务人员看。 当我取得业务部门的批准后，我就能够制作开发者图和服务图。服务图是针对高管的，以便确保他们对咱们正在做的事件有一个较高层次的理解。开发者图是针对那些将要施行解决方案的工程师的。 一旦构建起解决方案，咱们就能够更新基础设施图，将新的工作涵盖进来。 一张图片抵过一千个词汇，但架构图可能胜过五千个。可能让人们轻松、疾速地了解您的想法，是成为一名优良的解决方案架构师的要害。 可能为不同的受众建设不同类型的图表，您就为胜利做好了筹备。 P.S. - 我习惯应用 draw.io 来构建图表。这是一个收费的工具，它提供了制作好看详尽的图表、模型和图示所须要的所有资源。 文章作者： Allen Helton Allen Helton for AWS Community Builders ...

互联网的倒退，无时无刻不在争分夺秒，更疾速的研发落地，意味着能抢占市场先机，所以研发效率始终是研发工程师关注的外围问题之一。本文以Web我的项目为例，从架构设计、辅助工具、编码技巧、测试提效等视角，给出一些可疾速落地的实用小技巧，心愿对大家有所帮忙。 01架构设计：前后端拆散架构 传统MVC模型利用中，前后端在开发、部署环节存在不同水平依赖和耦合，随着业务体积一直收缩，不仅导致开发效率低下，代码也难以保护，前后端齐全拆散架构则能很好解决这些问题。 前后端拆散架构模式实现：在开发环节进行前后端代码寄存拆散、开发职责拆散，在部署环节进行利用部署拆散，前后端之间通过HTTP申请进行通信 。前后端拆散的开发模式与传统模式相比，晋升开发效率、加强代码可维护性。咱们在施行过程中次要从以下几个方面切入： 一、职责拆散：前后端代码库拆散，后端专一于后端管制层（RestfulAPI）、服务层、数据拜访层；前端专一于前端管制层（Nodejs）、视图层。 二、开发方式：前后端拆散是各自分工，并行协同麻利开发，后端提供Restful API，并给出具体文档阐明及测试用例，以保障API的可用性，升高集成危险；前端人员发送API申请(GET, POST等)获取数据（JSON，XML）进行页面的组装和渲染。 三、交互方式：前后端之间通过HTTP进行交互，API实现之前，前端人员会应用mock server进行模仿测试，后端人员应用相应工具进行API单元测试（如：junit），不必相互期待；API实现之后前后端再对接测试。当然并不是所有的接口都能够提前定义，有一些是在开发过程中进行调整的。 四、部署形式：前后端资源进行拆散部署，前后端可利用nginx做反向代理，如：Java + nodejs + nginx 形式进行交互。 02辅助工具：巧用脚手架 软件工程畛域，脚手架能够解释为帮忙开发人员在开发过程中应用的开发工具、开发框架，应用脚手架你毋庸从头开始搭建或者编写底层软件，帮忙咱们大幅缩小反复工作。 在工作中，当我的项目波及多人配合，非研发工作量就会占很大比例，这些工作很干燥，却又不得不做。在惯例的Web团队开发工作中，咱们要频繁对测试数据增删查改，要保护每个接口的文档，要对未实现的接口进行Mock，这些工作甚至占用时长比编写代码还要久。脚手架工具，能帮咱们解决这些麻烦，上面举几个例子： 一、测试数据批改：罕用的有phpMyAdmin，几分钟即可配置实现，生成一个可对mysql进行治理的后盾，可视化便捷治理测试数据，PM也能轻松应用。 二、文档的生成：有很多配置化的工具，接口文档可抉择TypeDoc、Doxgen等，性能文档可抉择mkdoc，通过简略的配置，就能实现文档编写工作。 三、接口Mock：可抉择Rap、Nei、Easy-Mock等，独自前端也能够用mock.js，前后端开发解耦，相互不阻塞期待，也缩小很多沟通老本。 因为程序员都很厌恶反复，每个相似问题都会有很多工具。下面只是列出几个常见场景帮忙关上思路，遇到其余场景也能够多去搜寻工具，尽量自动化解决。 03编码技巧：高质量前端编码 晋升前端代码品质，是晋升前端研发效率的重要动作。正当的代码逻辑 、模块设计以及齐备的工程化伎俩，可能保障模块稳固疾速的迭代交付。在理论开发中，常见的优化计划有以下几点： 一、重视逻辑形象：同样的代码在多处反复呈现，这样显然会进步代码的保护老本。咱们该当对反复代码进行逻辑形象，晋升代码复用性，并对这些形象做好单元测试。 二、正当设计模块：新增一个简略性能时，须要批改多处代码。这阐明性能短少封装，或者模块划分是不合理的。该当从新设计和划分模块，或者封装通用的性能 、积淀机制。 三、去除过多全局依赖：只批改了一处性能，却在其余意想不到的中央引发了Bug。这经常呈现在较为简单的模块中，新增性能依赖某种全局状态，而模块中散布着太多的全局变量和事件核心。面对这种状况，咱们该当革新旧代码，逐步去除对全局状态的依赖，并创立不依赖全局状态的新机制，在新的需要中去应用它。 四、一个变量只形容一种含意：当同一个变量的内容和含意随着程序运行一直产生扭转，会使该变量的理论取值难以预测，也就很难推断所在程序的行为。所以当值含意发生变化时，该当用新的变量指向它，变量名形容新值的内容和含意。 五、git提交标准：为了保障需要的高效率交付，团队该当制订对立的git提交标准，便于查找、合并和回滚。提交该当恪守 commitizen 标准，咱们能够通过引入 commit 工具治理提交，以及减少流水线工作阻塞最终公布，来强制保障提交的规范性。 04测试提效：自动化测试提速 在前端自动化测试的过程中，case的操作步骤之间须要期待页面的加载实现。页面的加载速度受各种不可控因素的影响：包含接口响应速度、网络速度、设施性能、前端渲染以及过渡动画时长等。为了确保测试用例的执行稳固，在书写case的过程中通常会设置一个比失常耗时更长的等待时间，这也就导致了自动化测试用例执行过程迟缓。 为了进步用例的执行效率，能够在执行过程中应用计算机视觉技术来实现主动断定页面是否加载实现。实现的思路如下：因为在产生设施交互后，设施的界面会从最后的稳固态过渡到一个空白的两头态，而后再由两头态逐渐加载实现进入下一个稳固态。依据此景象能够利用驱动（例如 minicap）疾速地截取设施界面的图像信息，而后通过实时剖析以后界面的页面空白信息，以及联合前后多帧之间的变动状况判断页面是否达到稳固状态。 计算机视觉技术的引入，实现了不同环境下的自适应。在加载速度较快场景升高了期待时长提高效率，在加载较慢场景减少了期待时长确保case的稳定性。

从深度学习技术被提出以来，始终践行着“think big”的理念。特地是当预训练技术被广泛应用之后，更多的数据联合更大的模型参数量会继续带来模型性能的晋升，这条定律一直被近期公布的各种大模型所验证。在刚刚过来的2021年，百度文心大模型中的ERNIE3.0、微软和英伟达联合推出的MT-NLP以及谷歌的Switch Transformer等等，参数量可达千亿甚至万亿。 在取得高性能大模型后，如何将大模型与业务联合实现落地变得尤为重要。以后预训练模型的落地流程可被演绎为：针对只有大量标注数据的特定工作，应用工作数据fine-tune预训练模型并部署上线。然而，当预训练模型参数量一直增大后，该流程面临两个无奈回避的问题。首先，随着模型参数量的急剧减少，大模型fine-tuning所须要的计算资源将变得十分微小，一般开发者通常无奈累赘。其次，随着AIOT的倒退，越来越多AI利用从云端往边缘设施、端设施迁徙，而大模型却无奈间接部署在这些存储和算力都极其无限的硬件上。 针对预训练大模型落地所面临的问题，百度提出对立特色示意优化技术（UFO：Unified Feature Optimization），在充分利用大数据和大模型的同时，兼顾大模型落地老本及部署效率。UFO技术计划的次要内容包含： All in One：设计视觉示意多任务协同训练计划，免去了上游工作fine-tuning的过程，实现单模型在智慧城市多个外围工作成果全面当先One for All：独创针对视觉多任务的超网络与训练计划，反对各类工作、各类硬件的灵便部署，解决大模型推理性能差的问题。 All in One：性能更弱小、更通用的视觉模型 之前支流的视觉模型生产流程，通常采纳单任务“Train from scratch”计划。每个工作都从零开始训练，各个工作之间也无奈互相借鉴。因为单任务数据有余带来偏置问题，实际效果过分依赖工作数据分布，场景泛化成果往往不佳。 近两年蓬勃发展的大数据预训练技术，通过应用大量数据学到更多的通用常识，而后迁徙到上游工作当中，实质上是不同工作之间互相借鉴了各自学到的常识。基于海量数据取得的预训练模型具备较好的常识齐备性，在上游工作中基于大量数据fine-tuning仍然能够取得较好的成果。不过基于预训练+上游工作fine-tuning的模型生产流程，须要针对各个工作别离训练模型，存在较大的研发资源耗费。 百度提出的UFO All in One模型，通过应用多个工作的数据训练一个功能强大的通用模型，可被间接利用于解决多个工作。不仅通过跨工作的信息晋升了单个工作的成果，并且免去了上游工作fine-tuning过程。UFO All in One模型研发模式可被广泛应用于各类多任务AI零碎，以智慧城市的多任务大模型为例，UFO All in One能够用单模型实现多个工作的SOTA辨认成果，同时多任务模型可取得显著优于单任务模型的成果，证实了多任务之间信息借鉴机制的有效性。 单模型笼罩智慧城市4大工作智慧城市是目前计算机视觉技术最重要的利用场景之一，在智慧城市的各个工作中，往往要同时解决人脸、人体、车辆和通用物体等指标，这对AI零碎的多任务协同能力提出了十分高的要求。现有的视觉模型大多只能检测或辨认其中的一类指标，百度通过UFO计划中的多任务协同学习技术，产出城市视觉UFO模型同时解决这4类工作，并在10项公开数据集上成果获得SOTA。上面具体介绍UFO的多任务协同训练计划。 工作设置与数据为验证计划的有效性且便于偏心比照，应用10项公开数据集进行训练和测试。各个数据集的统计信息如表所示： 对立各工作的配置从模型优化的层面来说，以往不同任务模型训练的batch size 、学习率乃至于优化器都各不相同。为了不便后续的多任务训练，UFO计划对立了各个工作的模型构造以及优化办法。工作配置如下表所示： 异构数据采样策略和Drop Path正则技术多任务学习首先面临的问题是如何构建Batch。罕用的形式有两种，一种是同数据域的Batch组成，即Batch内的数据均来自同一个工作，通过不同的Batch抉择不同的工作来保障训练所有工作。另一种是不同数据域的 Batch 组成，即Batch 内的数据来自不同的工作。同数据域的Batch组成面临的问题是当模型中应用BatchNorm这一常见的操作时，因为训练时的统计值（单任务统计值）和测试时的统计值（多任务统计值）差别较大，导致模型成果较差。如下表所示，通过ResNet50构造在人体Market1501和物品SOP两个工作中验证，应用混合数据域计划能够大幅提高两工作的成果。 在四个工作中，人体和物品的训练集数量最小，都只有6万张图片左右，而人脸和车辆则各有约500万和40万张图片。因而在多任务训练过程中，呈现出了人体、物品疾速过拟合，而人脸和车辆欠拟合的景象。为解决各个工作数据不平衡导致的过拟合问题，通过在训练过程中应用Drop Path正则化办法，在人体和物品工作中实现mAP1%~3%的晋升，同时其余工作成果持平或更好。 单模型刷新10项公开数据集SOTA后果基于多任务协同训练计划失去的城市视觉All in One UFO模型，和之前的单任务SOTA后果相比，在4个工作的10个测试集上都达到了新的SOTA，同时相比应用同样模型构造的单任务后果，在少数工作上UFO也体现的更好，证实了多任务之间信息借鉴机制的有效性。 在上图中，灰色示意示意城市视觉All in One UFO模型的后果，橙色示意和UFO模型应用雷同模型构造的单任务后果，蓝色示意之前同样数据集上最优的单任务后果。以上所有后果都不应用预训练数据，同时无重排序策略。 One for All：灵便、可伸缩的弹性部署计划 受算力和存储的限度，大模型无奈间接部署在边缘设施上。一个针对云端设施开发的模型要部署到边缘设施或端设施时往往要进行模型压缩，或齐全从新设计，而预训练大模型的压缩自身须要消耗大量的资源。 另外，不同工作对模型的性能和性能要求也不同，例如人脸识别门禁系统只需具备人脸识别性能即可，智慧社区的管控零碎则须要同时具备人脸识别和人体剖析的能力，局部场景还须要同时具备车型辨认及车牌辨认能力。即使是同样的人脸识别工作，门禁系统和金融领取零碎对模型的精度和性能要求也不同。目前针对这些工作往往须要定制化开发多个单任务模型，加之须要适配不同的硬件平台，AI模型开发的工作量显著增长。 针对大模型的开发和部署问题，UFO给出了One for All的解决方案，通过引入超网络的概念，超网络由泛滥稠密的子网络形成，每个子网络是超网络中的一条门路，将不同参数量、不同工作性能和不同精度的模型训练过程变为训练一个超网络模型。训练实现的One for All UFO超网络大模型即可针对不同的工作和设施低成本生成相应的可即插即用的小模型，实现one for all tasks 和one for all chips的能力。 ...

分页查问是一个很常见的性能,对于分页也有很多封装好的轮子供咱们应用。本文通过应用SpringBoot+Mybatis-plus 实现前端后端的分页性能,并没有应用插件来实现,前端次要是应用Thymeleaf来渲染分页的页码信息。前段页面分页代码<nav class="mt-5" th:if="${pageInfo.totalPage>0}" th:fragment="pagination"> <!-- align-items-center --> <ul class="pagination justify-content-center"> <li th:class="|page-item ${pageInfo.pageNum==1?'disabled':''}|"> <a class="page-link" th:href="@{${pageInfo.path}(pageNum=${pageInfo.pageNum}-1)}">&laquo; Previous</a> </li> <li th:class="|page-item ${i==pageInfo.pageNum?'active':''}|" th:each="i:${#numbers.sequence(pageInfo.getFrom(),pageInfo.getTo())}"> <a class="page-link" th:href="@{${pageInfo.path}(pageNum=${i})}" th:text="${i}">1</a></li> <li th:class="|page-item ${pageInfo.pageNum>=pageInfo.totalPage?'disabled':''}|"> <a class="page-link" th:href="@{${pageInfo.path}(pageNum=${pageInfo.pageNum+1})}">Next &raquo;</a> </li> </ul></nav>pageInfo.pageNum 依据本人的逻辑定义pageInfo.path 不便将整个分页片段援用到其余页面,如果不须要被援用,间接写死门路也能够管制层Controller @RequestMapping("discuss/{userId}") public ModelAndView getIndexPage( PageInfo pageInfo, @RequestParam(name = "orderMode", defaultValue = "0") int orderMode) { ... ModelAndView mav = new ModelAndView(); pageInfo = new PageInfo(); page.setPath("user/discuss/" + userId); pageInfo.setPageNum(pageNum); // 这里把文章分类带到页面header实现动静加载分类 IPage<Post> postIPage = postService.postPage(orderMode, pageNum); pageInfo.setTotal(postIPage.getTotal()); pageInfo.setTotalPage(ObjUtils.toInteger(postIPage.getPages())); List<Post> records = postIPage.getRecords(); pageInfo.setRows(records); List<Map<String, Object>> discussPosts = new ArrayList<>(); ... mav.addObject("pageInfo", pageInfo); mav.addObject("orderMode", orderMode); mav.addObject("discussPosts", discussPosts); mav.setViewName("site/my-post"); return mav; }page.setPath("user/discuss/" + userId); 门路最前边必须退出‘/’ ,如果仅是 user/discuss/,点击分页的时候会多出一层 ...

何俊泽会让人感觉到，他是一个邻家的阳光大男孩。尽管大学毕业不久，但他对技术的了解上所体现的成熟和幼稚，使得共事们都不得不赞之「后生可畏」。 以下是何俊泽与 ONES 的故事。 ONES 的技术口碑足够好我祖传三代都善于烹饪粤菜。我从小就喜爱吃美食，本人也很会做菜，不仅是粤菜，湘菜、川菜等也会做。 烹饪是一种不谈话的学习。在这个过程中，我会一直地尝试搭配食材，看怎样才能吃起来更鲜、更香。 这样导致我吃饭的口味会很挑。与此同时，我对工作的抉择也很挑，有清晰的职业规划。2021年8月，经由李雅堂的外部推荐，我退出了 ONES ，尔后我意识到了：这就是我心愿短暂待上来的公司。 其实，深圳的前端技术圈子不算大的，所以，哪家公司的技术口碑足够好，很快就会流传开来。我在圈子里得悉，ONES 有一条「坚定不做定制」的产品红线。我很拜服这种做法的思路和勇气，因为在我所理解过的公司里，没有哪一家敢公开这样说「不碰定制」的。 你想啊，做企业必定是要赚取利益的，但不做定制业务就意味着要放弃大量的短期「快钱」利益。而当 ONES 可能说到做到，就是不染指定制业务——在咱们搞技术的人眼里，这些都是很值得观赏、很有价值的闪光点，因为 ONES 不只想着盈利，而是真正想做好产品。 听其言，观其行。到底是不是真的想做好产品，看 ONES 的口头就会失去答案。在其余一些公司，假使发现了技术上的问题，只是简略地记录在文档上，后果是不了了之。 但在 ONES ，会有一个常态化的自我反馈机制。例如，每次我的项目迭代之后，都会有深度分析式的复盘，针对开发中所解决的难题，尝试总结出方法论：会不会有更好的计划、当前怎么躲避问题的呈现，等等。 也就是说，ONES 有着很强的自我更新迭代的意识，这让工程师们心里感觉很虚浮，这一点对于开发人员来说，是蛮有吸引力的，因为不是所有公司都会有这种能源去推动迭代的。 公司有很好的信赖气氛尽管我来 ONES 工夫不长，但我看到了在这里的成长通道，晓得怎么沿着阶梯一步一步走上去。我来 ONES 求职时，申请的职位是想退出技术委员会。 针对我的指标，HR 倡议我尝试尽量多的岗位，在不同的部门学习不一样的货色：能够先去交付组，同时学习优化方面的常识；当前体现得足够好的话，就能够到根底组去；在根底组做得好的话，到那时候就能够挑战退出技术委员会了；更进一步的话，能够尝试带团队了。 HR 会给新共事提供布局职业路径参考，这让人感到很安心。有过来人说，工作了三五年的人，有可能陷入工作迷茫期，如果没有清晰的回升通道，说不准就产生倦怠感。ONES 充分考虑到如何给予共事们职业前景的信念，这些做法都很体贴。 话又说回来，为什么 HR 置信我能「一路打怪」降级下来呢？答案是：不仅仅是 HR ，整个公司都有着很好的相互信任气氛。 例如，如果我对共事们说，我会在某个时间段实现开发。那么，共事们都会给予足够的信赖，不会每天都来催问做完没。之前，我在其余公司工作时，有过被重复催问进度的体验，这就是不信赖的体现。过后，我甚至试过一天之内被催两到三次。 当初，在 ONES 的开发过程中，团队我的项目管理者不会过多督促。给予咱们信赖的同时，咱们遇到的危险也会及时反馈给他，如果有任何问题，大家一起协力互助，齐全是以做好事件、失去最好后果为导向的。 ONES 对员工的信赖，背地是对能力真正的尊重。在之前我所工作的公司，依照我的工作年限，我只能算是高级工程师。但在 ONES ，当我表白了对技术的了解、对产品的认识，以及对将来倒退的布局，却失去了共事们很高的评估，让我感觉取得了很大的认可，也真心感触到 ONES 是一家不考究论资排辈的公司。 好奇心使得我有了爆发式的成长。但我深知成长的还不够，在技术方面还要承受重复的自我捶打，还要基于好奇心驱动学习更多的货色，动摇地走在永无止境的研发路上，因为我置信：世界上没有解不开的

AccessControlFilter访问控制过滤器,继承PathMatchingFilter过滤器,重写onPreHandle办法.isAccessAllowed 是否容许拜访onAccessDenied 是否回绝拜访 咱们通过重写上边两个办法来管制过滤逻辑,实现以后的需要,用户不登录点赞提醒请登录定义一个LoginAuthFilter继承AccessControlFilter前端js渲染脚本 // 前端弹窗的js代码private static final String JS = "<script type='text/javascript'>var wp=window.parent; if(wp!=null){while(wp.parent&&wp.parent!==wp){wp=wp.parent;}wp.location.href='%1$s';}else{window.location.href='%1$s';}</script>";private String loginUrl = "/login";重写isAccessAllowed办法判断用户是否登录 @Overrideprotected boolean isAccessAllowed( ServletRequest request, ServletResponse response, Object mappedValue) throws Exception { Subject subject = SecurityUtils.getSubject(); if (null != subject) { if (subject.isRemembered()) { return true; } if (subject.isAuthenticated()) { return true; } } return false;}重写onAccessDenied办法,ajax申请返回谬误code,提醒‘请登录’否则跳转到登录页查看残缺代码片段移步 成果如下图点击点赞按钮查看成果

申请、下载SSL证书腾讯云,阿里云都反对收费证书,这里我用的是阿里云步骤如下: 批改application.properties文件将.jks文件与application.properties同级在application.properties文件中增加以下几行配置信息 server.port=443server.custom.httpPort=80#自定义启动banner文件的门路#============================== https配置 ========================================server.ssl.key-store=classpath:daishu.jksserver.ssl.key-store-password=server.ssl.key-store-type=JKS查看到具体的HttpsConfig类移步

导语 在IT技术突飞猛进倒退的明天，信息化技术给企业带来了很多红利。但部分的信息化曾经无奈满足企业倒退的需要，于是，企业整体数字化转型成为当下最热门的话题，也是企业所面临的最大的挑战。而很多企业十分困惑，什么是数字化转型？数字化转型到底要做些什么工作？其实，当企业随着技术提高而采纳全新的翻新形式来开展业务时，他们就曾经在数字化转型的路上了。这是一个应用数字化工具从根本上实现转变的过程，通过技术和文化改革来改良或替换现有的资源。 党的十九大报告提出，推动互联网、大数据、人工智能和实体经济深度交融。以互联网、大数据、云计算、人工智能等为代表的技术粗浅扭转了宏观主体经济行为，极大施展了信息对晋升经济效率的重要作用，踊跃带动了我国经济转型降级，成为重要经济倒退新动能。除土地、劳动力、资本和技术等传统经济增长因素外，信息已成为一个推动经济增长的重要因素。更加高效地获取、使用信息，成为企业具备弱小竞争力的重要标记。 由此能够看出，数字化转型在企业倒退中的重要位置。所以，笔者认为，能够给数字化转型下这样的定义： 适应新一轮科技反动和产业改革趋势，一直深入利用云计算、大数据、物联网、人工智能、区块链等新一代信息技术，激发数据因素翻新驱动潜能，打造晋升信息时代生存和倒退能力，减速业务优化降级和翻新转型，革新晋升传统动能，培养倒退新动能，发明，传递并获取价值，实现转型降级和翻新倒退的过程。 那么，数字化转型到底须要做些什么工作呢？ 一、总体框架 图1 数字化转型框架 次要视角：包含倒退策略、新型能力、系统性解决方案、治理体系和业务翻新转型五个视角，明确数字化转型次要工作，并给出工作间的关联关系。 过程办法：蕴含办法体系，针对数字化转型的五个视角，别离给出其对应的过程联动形式机制，并构建相干办法机制之间的相互作用形式。 倒退阶段：明确数字化转型的门路体系，将数字化化转型分为：初始级数字化阶段、单元级数字化阶段、流程级数字化阶段、网络级数字化阶段、生太级数字化阶段等五个阶段，并别离明确数字化转型五个视角在不同倒退阶段的次要施行要求。 二、次要视角 以价值体系优化、翻新和重构是数字化转型的根本任务，企业应从倒退策略、新型能力、系统性解决方案、治理体系和业务翻新转型等五个视角登程，构建系统化、体系化的关联关系，零碎有序的推动数字化转型，翻新价值发明、传递、反对、获取门路和模式，如下图，以价值体系优化、翻新和重构为根本任务的五个视角和各视角间的关联关系： 倒退策略提出价值主张：依据数字化转型的新局势、新趋势和新要求，倒退策略要求提出新的价值主张。 新型能力反对价值发明和价值传递：依据价值主张新要求，新型能力视角打造反对价值发明和传递的新型能力体系。 系统性解决方案提供价值反对：系统性解决方案视角翻新价值反对的因素实现体系，造成反对新型能力打造、推动业务翻新转型的系统性解决方案。 治理体系提供价值保障：治理体系视角改革价值保障的治理机制和管理模式，构建反对新型能力打造、推动业务翻新转型的治理体系。 业务翻新转型实现价值获取：依据价值主张新要求，基于打造的新能力体系、造成的零碎解决方案和构建的治理体系，业务翻新转型视角造成反对最终价值获取的业务新模式和新业态。 三、过程办法 新型能力建设是数字化分心的外围门路，企业应依照价值体系优化、翻新和重构的要求，辨认和打造新型能力（体系），将新型能力建设贯通数字化转型全过程，以新型能力建设全方位牵引转型流动，针对数字化转型的五个视角，系统化、体系化建设倒退策略、新型能力、系统性解决方案（因素）、治理体系和业务翻新转型等五个过程联动办法机制，并建设上述办法机制之间的相互作用关系，如下图： 四、倒退阶段 数字化转型共分为五个倒退阶段，即初始级数字化阶段、单元级数字化阶段、流程级数字化阶段、网络级数字化阶段、生态级数字化阶段。 数据是数字化转型的要害驱动因素，不同倒退阶段的企业在获取、开发和利用数据方面，总体呈现出由部分到全局、由内到外、由浅到深、由关闭到凋谢的趋势和特色。基于数据因素在不同倒退阶段所施展驱动作用的不同，数字化转型的倒退策略、新型能力、系统性解决方案、治理体系、业务翻新转型等五个视角，在不同倒退阶段有不同的倒退状态和特色，如下图所示： 初始级数字化阶段 处于初始级数字化阶段的企业总体特色体现为： 在繁多职能范畴内初步发展了信息（数字）技术利用，但尚未无效施展（数字）技术赋能作用； 初步利用信息（数字）技术获取、开发和利用数据，但尚未无效反对和优化主营业务范畴内的生产经营治理流动； 处于初始级数字化阶段的企业，各视角的典型状态和特色次要体现为： 倒退策略视角。倒退策略中尚未明确或初步提及信息（数字）技术利用相干内容，尚未制订信息（数字）技术利用相干的专利布局。 新型能力实视角。打造了新型能力，但尚未无效建成主营业务范畴内的新型能力。 系统性解决方案视角。初步发展信息（数字）技术利用，或初步发展基于信息（数字）技术的（系统性）解决方案策动与施行。 治理体系视角。管理模式为教训驱动型，各项业务流动次要由管理人员依据教训做出决策。 业务翻新转型视角。尚未实现基于数字化的业务翻新。 单元级数字化阶段 处于单元级数字化阶段的企业总体特色次要体现为： 在次要或若干繁多职能范畴内发展了（新一代）信息技术利用，晋升相干单项业务的运行规范性和效率。 次要利用（新一代）信息技术实现业务单元（部门）数据的获取、开发和利用，施展数据作为信息沟通媒介的作用，解决单元接信息通明问题，晋升业务单元的资源配置效率。 处于单元级数字化阶段的企业，各视角的典型状态和特色次要体现为: 倒退策略视角。在倒退策略和专项规划中明确提出数字化内容，指标定位次要是晋升业务规范性和运行效率，数字化内容纳入了部门级年度计划和绩效考核。 新型能力视角。可能经营（新一代）信息技术伎俩反对主营业务繁多职能优化的新型能力建设、运行和优化，所造成的新型能力次要在相干单项业务中应用。 系统性解决方案视角。面向繁多职能范畴内新型能力建设、运行和优化，发展必要的设施设施革新，利用（新一代）信息技术伎俩和工具，发展相干单项业务优化和职能职责调整，基于繁多职能范畴内及相干单项业务数据采集发展单元级数据建模等。 治理体系视角。管理模式是职能驱动型，可能基于繁多职能范畴内或相干单项业务数据发展辅助管理决策。领导器重并踊跃推动（新一代）信息技术利用，设置了专门团队发展（新一代）信息技术利用与运维，建设单项利用与运维机制等。 业务翻新转型视角。次要或要害单项业务实现数字化，造成（新一代）信息技术伎俩和工具反对下的业务运行模式。 流程级数字化阶段 处于流程级数字化阶段的企业总体特色次要体现为： 在业务线范畴内，通过流程级数字化和传感网级网络化，以流程为驱动，实现要害业务流程及要害业务与设施设施、软硬件、行为流动等因素间的继承优化。 次要基于业务流程数据的获取、开发和利用，施展数据作为信息媒介的沟通作用，解决跨部门、跨业务环节的流程级信息通明问题，晋升业务流程的集成交融程度和资源配置效率。 有条件的企业开始摸索施展数据作为信用媒介的作用，发展基于数据的价值在线替换，进步资源的综合利用程度。 处于流程级数字化阶段的企业，各视角的典型状态和特色的次要体现： 倒退策略视角。以实现业务综合集成为外围，制订数字化转型专项战略规划，已在策略层面意识到数据的重要价值，并将数字化转型年度计划和绩效纳入企业整体考核体系。新型能力视角。实现反对主营业务集成协同的流程级能力的建设，且新型能力的能力模块可被该流程高低相干环节无效利用。系统性解决方案视角。面向流程级能力建设、运行和优化，构建传感网级网络，集成利用IT软硬件资源，发展跨部门、跨业务环节、跨层级的业务流程优化设计和职能职责调整，基于次要设施和各业务零碎数据采集和集成共享，构建并利用零碎级数字化模型。治理体系视角。管理模式为流程驱动型，可能发展跨部门、跨业务流程的数字化集成治理，有企业决策层和专职一级部门兼顾推动数字化转型工作，造成了流程驱动的数字化零碎建设、集成、运维和继续改良的标准规范和治理机制。业务翻新转型视角。在企业要害业务均实现数字根底之上，沿着纵向管控、价值链和产品生命周期等维度，次要或要害业务线实现了业务集成交融。 网络级数字化阶段 处于网络化数字化阶段企业总体特色体现为： 在整个企业范畴内，通过企业（企业）级数字化和产业互联网级网络化，推动企业内全因素、全过程互联互通和动静优化，实现以数据为驱动的业务模式翻新。 次要基于整个企业范畴内数据的获取、开发和利用，施展数据作为信息沟通媒介和信用媒介的作用，解决整个企业信息通明问题，并基于数据实现整个价值网络化在线替换，晋升企业价值网络化发明能力和整个企业资源综合利用程度。 有条件的企业开始摸索用数据迷信从新定义并封装生产机理，构建基于数据模型的网络化常识共享和技能赋能，进步企业创新能力和资源开发潜能。 处于网络化数字化阶段的企业，各视角典型状态和特色次要体现为： 倒退策略视角。制订了以数字企业（企业）为核心内容的企业倒退策略，在企业倒退策略中明确将数据作为要害策略资源和驱动因素，减速推动业务翻新转型和数字业务培养。构建数字企业成为企业年度内的核心内容，并建设笼罩全年的绩效考核体系。 新型能力视角。实现反对企业全局优化的网络级的能力建设，实现新型能力的模块化、数字化和网络，可能在整个企业范畴内进行按需共享和利用。 系统性解决方案视角。建设数字企业的系统集成架构，业务根底资源和能力实现平台化部署，反对按需调用，OT网络和IT网络实现协定互通和网络互通，基于企业内全因素、全过程数据在线主动采集、替换和集成共享，建设和利用企业（企业）级数字孪生模型。 治理体系视角。治理形式为数据驱动型，实现笼罩企业（企业）全过程的自企业治理。建设企业（企业）级数字化治理领导机制和协调机制，造成数据驱动的数字企业治理体系，实现数据、技术、流程和组织等四因素的智能协同、动静优化和互动翻新。 业务翻新转型视角。基于次要或要害业务在线化运行和外围能力模块化封装和共享利用等，实现网络化协同、服务化延长、个性化定制等业务模式翻新。 生态级数字化阶段 处于生态级数字化阶段的企业总体特色次要体现为： 在生态企业范畴内，通过生态级数字化和泛在物联网级网络化，推动与生态合作伙伴间资源、业务、能力等因素的凋谢共享与协同单干，独特培养智能驱动型的数字新业务。 ...

导语 工业和信息化部印发《新型数据中心倒退三年行动计划（2021-2023年）》（工信部通信〔2021〕76号，下称《行动计划》）具体论述了我国将来三年新型数据中心的中期建设要求，其中讲到“打算到2023年底，利用率方面，全国数据中心均匀利用率力争晋升到60%以上；算力规模方面，总算力规模超过200 EFLOPS，高性能算力占比达到10%；能效程度方面，新建大型及以上数据中心PUE升高到1.3以下，酷寒和凛冽地区力争升高到1.25以下；网络时延方面，国家枢纽节点内数据中心端到端网络单向时延原则上小于20毫秒。”旨在通过新型数据中心能更好撑持新一代信息技术减速翻新，放慢推动制作强国和网络强国建设。与传统数据中心相比，新型数据中心具备高技术、高算力、高能效、高平安等特色。 一组数据： 需要端：依据IDC预计，2021年寰球IT开销3.9万亿美元，云渗透率无望逐渐晋升至15%以上。2020年国内云计算市场规模在整体IT收入中占比6.2%，也将随着寰球趋势一直晋升。客户接受度逐渐晋升，IT架构向云迁徙趋势明确。 供应端：企业技术计划逐渐成熟，产品迭代日渐放慢，撑持云落地。云支出逐渐放量，将来无望放弃高增长，AWS及阿里云营收体现验证行业空间及后劲。 一、云计算技术 云计算（Cloud Computing）是一种通过网络对立组织和灵便调用各种ICT（information and communications technology）信息资源，实现大规模计算的信息处理形式。云计算利用分布式计算和虚构资源管理等技术，通过网络将扩散的ICT资源（包含计算与存储、利用运行平台、软件等）集中起来造成共享的资源池，并以动静按需和可度量的形式向用户提供服务。用户能够应用各种模式的终端(如PC、平板电脑、智能手机甚至智能电视等)通过网络获取ICT资源服务。云计算产业由云计算服务业、云计算制造业、基础设施服务业以及反对产业等组成。 因为数据出现爆炸性增长，人类对计算的需要大大增加，并且心愿随时随地获取，这将间接推动云计算成为数字经济时代的新型信息基础设施。 云计算服务类型分为三类： (1)基础设施即服务（IaaS)：向云计算提供商的集体或组织提供虚拟化计算资源，如虚拟机、存储、网络和操作系统。 (2)平台即服务(PaaS)：为开发人员提供通过寰球互联网构建应用程序和服务的平台。Paas为开发、测试和管理软件应用程序提供按需开发环境。 (3)软件即服务(SaaS)：通过互联网提供按需软件付费应用程序，云计算提供商托管和管理软件应用程序，并容许其用户连贯到应用程序并通过寰球互联网拜访应用程序。 云计算倒退至今曾经经验了十余年，回望过来十余年，在政策和市场的推动下，云计算行业疾速倒退。将来5G、物联网、人工智能等多种新兴技术减速与实体交融之际，云计算行业无望维持较高水平倒退，进入普惠发展期。从行业视角看，2006年是云计算元年，从AWS开始，越来越多的行业巨头和玩家入局云计算市场。云计算大抵经验了造成、疾速倒退和成熟阶段。目前，中国云计算产业倒退落后于美国5年左右，处于广泛应用阶段。云计算按提供的服务辨别大体可分为IaaS、SaaS、PaaS，还有一类比拟非凡的是公有云。 云计算为应用程序世界带来了微小的变动，使利用程序开发和部署的长期限度隐没。毫不夸大地说，过来十年中IT畛域的大多数翻新都是由云计算实现、催化或引起的。 近年来一种新的基于云的技术曾经呈现并日趋成熟，齐全可能彻底改变现有的技术生态系统，被称为无服务器计算（Serverless）。 二、无服务器计算 无服务器是一种云计算执行模型（CNCF指出，无服务器计算并不是指不须要服务器）云提供商在其中动静治理服务器的调配和配置。无服务器应用程序在无状态计算容器中运行，这些容器由事件触发、长期（可能继续一次调用）并由云提供商齐全治理。定价基于执行次数，而不是事后购买的计算容量。 其执行体系如下图所示： 与传统服务器或虚拟机上托管的应用程序相比，无服务器计算和容器都使开发人员可能以更低的开销和更大的灵活性构建应用程序，开发人员应应用哪种体系结构款式取决于应用程序的须要，但无服务器应用程序更具可伸缩性，并且通常更具老本效益。 容器提供了一个更轻量级的执行环境，使实例化更快，进步了硬件利用率，但它们不会扭转根本的利用程序运行过程。 应用无服务器时，底层容器或技术平台负责确保加载和执行利用程序代码，并确保有足够的计算资源可用于运行代码，无论它须要多少解决。 无服务器计算劣势： 三、Serverless不得不提到FaaS FaaS是一种实现无服务器计算的办法，开发人员在其中编写业务逻辑，而后在齐全由容器治理平台治理的容器中执行。 如下图所示： FaaS概念 性能即服务（FaaS）是一种云计算服务，容许开发人员将利用程序包作为函数进行构建，计算，运行和治理，而无需保护本人的基础架构。 FaaS 是一种事件驱动的执行模型，它在无状态容器中运行，这些函数通过应用来自FaaS 提供程序的服务来治理服务器端逻辑和状态。 FaaS 解决方案可在次要公共云上应用，并且能够在本地进行配置，从而为企业 IT 部门减少了重要的新性能，用于利用开发。获取云原生策略指南，筹备应用 FaaS 实现无服务器办法。 FaaS 基础架构通常是按需计量的，次要通过事件驱动型执行模型进行，因而它会随时待命，但不须要任何服务器过程在后盾继续运行（这一点与平台即服务 （PaaS）不同）。 一份来自CNCF的考察统计 CNCF发动了一份云原生技术在生产环境中应用的考察，其中考察了无服务器技术的增长趋势，结果显示38%的企业或组织曾经应用无服务器技术。 无服务器计算开源平台排名 Kubeless（从 2% 回升到 42%） Apache OpenWhisk（从 12% 回升 25%） OpenFaas（从 10% 回升 20%） 目前支流的FaaS开源平台简略比照： 无服务器计算私有云厂商比照 FaaS服务赛道内，目前云计算厂商次要诸如AWS Lambda、微软Serverless、阿里云SAE、腾讯SCF、华为云FunctionStage等均已布局无服务器计算畛域。 ...

导读 10月23-24日，以“商业翻新的力量”为主题的2021商业翻新大会在北京隆重召开。来自各行业的出名企业家、专家学者、生态搭档、投资机构以及媒体代表共聚一堂，共话新技术、新价值、新生态，共享创变教训，共建企业数智化新将来，见证商业翻新的力量。大会取得新华社、新华网、地方广播电视总台央视频等国家级媒体，地方重点新闻网站、报纸和地方新媒体平台、行业媒体、自媒体、新媒体等多方媒体的报道和关注。 新华社发表了题为《用友商业翻新价值全面助力企业数智化转型》的新闻报道。报道当日仅5小时浏览量冲破16万+，截止到目前，浏览量已冲破60万+。 同期，新华社大数据智库云在其官网发表《如何数智化转型？2021商业翻新大会上的观点是……》对大会的深度钻研报道。 以下内容来自新华社大数据智库云发表的《如何数智化转型？2021商业翻新大会上的观点是……》文章。 “十四五”布局提出，“放慢数字化倒退，建设数字中国，到2025年数字经济外围产业增加值占GDP比重晋升至10%。” 数据显示，2020年我国数字经济总量跃居世界第二。数字经济正成为重组寰球因素资源、重塑寰球经济构造、扭转寰球竞争格局的要害力量。 数字经济不仅是现代化经济体系的重要组成部分，更是推动经济高质量倒退的重要驱动力，正在对传统产业进行全方位、全链条的革新。 《麻省理工学院斯隆治理评论》一份钻研表明，90%的受访企业高管认为，他们所在的行业将被数字化趋势颠覆。 现在与过来已大不同，竞争格局变了，消费者需要变了，营销渠道变了，客户互动形式也变了…… 传统企业面对数字技术带来的重大时机与挑战如何应答？10月23-24日，以“商业翻新的力量”为主题的2021商业翻新大会上，来自各行业的出名企业家分享了他们的观点和摸索、实践经验。 企业数智化：价值是方向，倒退是指标 “数智化”一词最早见于2015年北京大学“知本财团”课题组提出的考虑引擎课题报告。最后的定义是：数字智慧化与智慧数字化的合成。 那什么是数智企业？用友网络董事长兼CEO王文京认为，客户导向、员工能动、生态共荣、数据驱动、实时感知和智能经营是数智企业该当具备的六个个性，可能实现企业支出增长、老本升高、体验加强、品质进步、平安、环保等各方面价值。王文京认为，数智化是门路，最终目标是为了企业实现更强的竞争劣势，更高的经营绩效，以及更可继续的倒退。 华为公司董事、首席信息官陶景文认为，“数智化转型就像人的生物进化一样，具备阶段性、颠覆式的，有断裂带的特点，在倒退过程中，就像蛹化蝶的过程，是一个新生的过程。” 王文京认为，数智化是门路，最终目标是为了企业实现更强的竞争劣势，更高的经营绩效，以及更可继续的倒退。 来自中国电子、双良团体、苗乡三七等多位企业的相干负责人介绍的倒退教训，印证了这一点。 中国电子经营管理部副主任唐路介绍称，在实践中，中国电子围绕打造国家网信产业核心技术和组织平台的指标，从需要维度，保持平安为先、保持全面上云、保持融入挪动。现在中国电子18万名员工可能随时随地随心平安上云，实现了平安、高效、节能办公。从治理维度，中国电子聚焦数据治理、聚焦单干共建；从技术维度，关注利用重构和中台赋能。 以配备制造业为外围主业的双良团体，正致力以数智化推动企业提质增效。双良团体总裁马培林介绍，借助友空间的利用，双良团体曾经将协同晋升到了团体管控的新高度：通过与团体外部泛滥零碎数据的集成买通，造成一个全员利用的超级APP，极大进步了企业的治理经营效率。 数智技术利用和产业互联网建设，正在赋能农业与流通服务，从新构建更宽泛的产业生态。苗乡三七董事长余育启介绍，苗乡三七在交融用友商业翻新平台与苗乡三七行业教训的根底上，采纳共创共建模式搭建起产业级、社会级商业翻新平台——三七产业互联网平台。该平台基于精准的用户场景，从企业到产业，重构传统作坊式运行模式，买通了三七产业链农端、工端、商端的全流程。通过三七产业互联网平台，三七的传统农耕和贸易模式通过一系列革新、降级，实现了商业翻新和变质，推动了所在产业的设施化、有机化、数智化发展。 以商业翻新平台推动数智化转型 数字经济时代，技术在企业中的利用，正在从聚焦企业外部流程优化，逐步过渡到面向产业链上下游、企业全生命周期的商业翻新。 国内数字化相干咨询服务专家团队调研结果显示，在近百家大中型企业团体的数字化转型策略与实际中发现将来企业数字化将次要围绕三大外围策略开展:聚焦组织外部经营的“数字化治理”，聚焦组织内部客户经营的“数字化经营”，聚焦产品、服务、商业模式翻新的“数字化商业”。 数字化治理：聚焦财务、人力、制作、供应链等外部经营环节，通过利用数字化技术，实现治理经营数字化，赋能员工，激活组织，升高现有价值中各环节的老本，晋升经营效率。 数字化经营：聚焦营销、服务、渠道等围绕客户体验的经营，通过利用数字化技术，实现数字化麻利经营，更精准管制营销通路和满足客户需要，减少营收和利润。 数字化商业：聚焦产品、服务、商业模式的数字化翻新，通过数字化技术利用对企业以后产品和服务的数字化进行革新，或者开发新型商业模式，利用数字化技术驱动业务和业绩增长，构建全新的社会化、数字化产业新生态。 数字化营销：即利用智能批发科技，重构人、货、场，实现营销精准化、营销场景化、营销社交化、营销个性化。 智能化制作：即基于新一代信息通信技术与先进制作技术深度交融，贯通于设计、生产、治理、服务等制作流动各个环节的智能化、数字化转型。 为推动企业数智化与商业翻新倒退，2020年8月，用友公布了商业翻新综合服务平台-用友BIP（商业翻新平台），将云服务从产品服务模式升维到平台服务模式。 用友网络高级副总裁张成雨介绍，用友BIP继续进化，基于对立数智底座，将敏态与稳态利用相结合，通过交融服务群为企业客户与合作伙伴提供网络协同、连贯资源、数据智能、重塑流程、麻利翻新等五大外围价值。 依据Gartner（高德纳征询公司）报告显示，用友是寰球企业级应用软件TOP10中惟一的亚太区厂商，也是惟一入选寰球云ERP市场指南的中国厂商。

中转大会精彩，请点击>>>官网地址

线上会议、在线教育、电商直播等多个场景的衰亡，也使得实时互动技术从幕后走到台前，失去了更多人的关注。编解码、网络传输、计算机视觉等 RTE 相干的一系列技术也正焕发出更强的生命力。2021 年，在深度学习、5G 等技术的加持下，RTE 会进一步催生哪些可能？ 声网Agora 开发者社区联结 InfoQ 独特策动，邀请了声网Agora 开发者社区中的多位技术专家，从视频传输、计算机视觉、编解码规范倒退、WebRTC、机器学习、音频技术等角度，独特撰写「2021 实时互动技术瞻望系列」，一窥技术新趋势。本文作者微帧科技首席科学家兼联结创始人 Zoe Liu。本系列内容由声网 Agora 开发者社区 与 InfoQ 联结策动，并由 InfoQ 审校，首发于 InfoQ。 2018 年 6 月，AOM 联盟（Alliance for Open Media，凋谢媒体联盟）公布了新一代视频编码标准——AV1（Alliance for Open Media Video 1）。至今 AOM 联盟共有 47 家企业会员，其中包含 14 名理事会成员（Board Members）和 33 名 Promoter 会员。 AV1 的零号版本，起始由同样开源、免版税的 VP9 编解码代码库 libvpx 衍生而来，同时吸纳了 Google VP10、Mozilla Daala 以及 Cisco Thor 三款开源编码我的项目中的研发成绩。截止 2018 年 6 月 AV1 封稿，AV1 相比其前身 VP9，共推出了 100 多个簇新的编码工具，代表了业界最新的编码技术。 ...

本节课程为《继续交付办法与实际》，将围绕三个方面开展，为什么要做继续交付、如何做到高效的继续交付以及继续部署。 为什么要做继续交付01 软件交付流程想要了解为什么要做继续交付，就要先理解软件交付流程。 传统软件交付流程通常包含四个步骤： → 首先业务人员会诞生一个软件的想法； → 而后开发人员将这个想法变为一个产品或者性能； → 通过测试人员的测试之后提交给用户应用并产生收益； → 最初运维人员参加产品或性能的前期运维。 02 传统软件交付的问题和窘境通过剖析以上流程，能够发现一些传统软件交付流程存在的问题。 ①业务人员产生的需要文档沟通效率较低，有时会产生需要文档形容不明确、需要文档变更频繁等问题。 ②随着开发进度的推动，测试人员的工作量会逐渐减少，测试工作的比重会越来越大。而且因为测试方法和测试工具无限，自动化测试水平低，无奈很好地把控软件品质。 ③实在我的项目中运维的排期常常会被挤占，又因为手工运维繁琐简单，工夫和技术上的双重压迫会导致运维品质难以保障。 因为存在以上问题，所以传统的软件交付常常会呈现开发团队破费大量老本开发出的性能或产品并不能满足客户需要这一双输的场面。由此能够总结出传统的软件交付存在两个层面的窘境： 从体现层来看，传统软件交付存在进度不可控；流程不牢靠；环境不稳固；合作不顺畅等窘境。 体现层的问题其实都是由底层问题引起的，从本源上来说，存在分支冗余导致合并艰难；缺点过多导致阻塞测试；开发环境、测试环境、部署环境不对立导致的未知谬误；代码提交版本凌乱无奈回溯；期待上线周期过长；我的项目部署操作简单常常失败；上线之后呈现问题须要紧急回滚；架构设计不合理导致产生谬误之后无奈精确定位等窘境。 03 继续交付的流程与劣势通过对传统软件交付问题的剖析和总结，继续交付应运而生，继续交付是一系列开发实际办法，用来确保让代码可能疾速、平安的部署到生产环境中。继续交付是一个齐全自动化的过程，当业务开发实现的时候，能够做到一键部署。继续交付提供了一套更为欠缺的解决传统软件开发流程的计划。 ①在需要阶段，摈弃了传统的需要文档的形式，应用便于开发人员了解的用户故事。 ②在开发测试阶段，做到继续集成，让测试人员尽早进入我的项目开始测试。 ③在运维阶段，买通开发和运维之间的通路，放弃开发环境和运维环境的对立。 继续交付具备以下几个劣势： ①继续交付可能无效缩短提交代码到正式部署上线的工夫，升高部署危险。 ②继续交付可能主动的、疾速的提供反馈，及时发现和修复缺点。 ③继续交付让软件在整个生命周期内都处于可部署的状态。 ④继续交付可能简化部署步骤，使软件版本更加清晰。 ⑤继续交付可能让交付过程成为一种牢靠的、可预期的、可视化的过程。 04 麻利开发与Devops继续交付依附麻利开发（Agile）和Devops两个组件的撑持能够更好地发挥作用。 麻利开发（Agile）次要作用于需要阶段和研发阶段。 Devops次要作用于开发测试和运维部署阶段。 在这里咱们次要解说一下Devops的相干常识。 （1）Devops的趋势 依据最近的一项个体钻研，DevOps的市场在2020年发明了约50亿美元的产值，预计到2022年，这个数字将达到约66亿美元。随着Devops的影响力不断扩大，目前DevOps曾经成为软件工程的支流模式。 （2）Devops效力 Devops的效力跟公布频率、部署工夫、均匀修复故障的工夫点、部署变更的失败率四个因素严密相干。通常在高效的团队内，公布频率会达到每天屡次公布、部署工夫和均匀修复故障工夫都小于一小时，部署变更的失败率也能维持在15%以下。 05 软件交付能力指标在评估互联网公司的软件交付能力的时候，通常会应用两个指标： ①仅波及一行代码的改变须要破费多少工夫能力部署上线，这也是外围指标。 ②开发团队是否在以一种可反复、牢靠的形式在执行软件交付。 目前，国外的支流互联网企业部署周期都以分钟为单位， Amazon、Google这些头部互联网企业单日的部署频率都在20000次以上。国内以百度、阿里、腾讯三大互联网巨头的数据来看，单日部署的频率也达到了单日8000次以上。高频率的部署代表着可能更快更好的响应客户的需要。 如何做到高效的继续交付01 继续交付办法为了能更好的做到高效的继续交付。在此咱们提供了一个三层叠加的继续交付办法。 首先最上层，继续交付的总指标是价值交付，要为用户交付有价值的内容。 而后第二层蕴含了业务、流程、组织三个维度。 在业务这一维度，次要通过精益、用户故事地图、看板三种形式来缩小业务部门与开发部门的沟通艰难。 在流程这一维度，次要集中于创立一个供开发、测试、运维人员应用的牢靠、可反复的流水线，将这种流水线利用于我的项目的流程中。 在组织这一维度，要求增强团队合作，进步我的项目品质和我的项目改良能力，并且引入了成熟度模型用于评估团队的能力层级。 如果没有技术能力的撑持，仅依附办法和指导思想不足以做到高效继续交付。所以第三层也是最重要的底层是技术层。技术层包含了基础架构和利用架构。基础架构引入了容器集群治理、研发工具平台、继续交付工具链。利用框架引入了浮现式设计、微服务框架还有可能抽离进去的配置化架构。 02 继续交付、继续集成、继续部署的关系要进一步构建牢靠可反复的流水线，首先就是要理清继续交付、继续集成和继续部署三者之间的关系。 简略来说继续集成和继续部署是继续交付的根底，继续交付包含但不限于继续集成和继续部署。 继续集成是蕴含了代码的编译、近代查看、单元测试工作的集成，尽管继续集成也能形成一条流水线，然而这条流水线并不残缺，而且集成并没有明确的指标。 近几年得益于虚拟机技术和容器技术的迅速倒退，继续部署也逐步变得简略高效，可能使用这些工具疾速将我的项目部署到例如准入环境、预生产环境等等各种环境中。 03 如何构建一个牢靠可反复的流水线在理清继续交付的关系后，须要通过继续交付来构建一条牢靠可反复的流水线，构建这条流水线的目标是为了让开发人员、测试人员、运维人员能更好的合作实现整个我的项目并上线到生产环境。 通过比照传统流水线和继续交付流水线，能更加清晰地展现出继续交付流水线的弱小。 在传统流水线中，首先代码提交要用过填写表单的模式进行版本申请，而后开发人员在离线环境上手工进行代码编译和单元测试，单元测试实现后须要撰写对应的测试报告文档并且向上提测，在零碎测试环节须要测试人员手动构建和部署测试环境，实现测试之后再次撰写测试报告，并且申请上线，在通过上线审批之后，在线上生产环境须要再次手动构建环境以及进行生产环境的测试，最终实现整体的开发。 在继续交付流水线中，代码合入到骨干之后会间接触发主动编译，主动编译实现之后会进行初步的自动化单元测试、模块测试和零碎测试，在测试过程中继续交付能够主动构建和部署环境。实现零碎测试之后会将问题抛出来，解决实现后再次提测，会自动化的再次进行零碎测试，通过零碎测试之后能够一键操作进行我的项目公布，并进行预上线，在实现预上线后，能够再次进行一键操作实现正式生产环境的上线。 通过两种流水线的比照，能够看进去，继续交付的流水线有显著的劣势。 理论生产中的产品级流水线，能够视为多个模块级流水线的组合，多个模块级流水线组合成为简单的多线并发的产品级流水线，最终能够实现整个我的项目的继续交付。 ...

简介： 作者是一名很一般的技术工程师，从14年毕业到当初工作了7年。本文将与大家分享一些退职场中的情理和教训，心愿能对大家有所启发和帮忙。 作者 | 抱真起源 | 阿里技术公众号 前言简略做个自我介绍，我是一名很一般的技术工程师，从14年毕业到当初工作了7年。一路走过去，感觉本人很侥幸遇到了很多伯乐，教会了我很多情理和职场教训。最近几年作为面试官也面试了很多同学，常常和很多候选人沟通分享一些本人学习成长的门路，也常常和很多新入职的同学口头分享一些工作心得。当初把这些的经验总结了一下，如果能对看到文章的同学有所启发及帮忙最好。 十条教训1 自我认知 很多新入职的同学，尤其是社招的同学，会对新的环境不适应（可能是共事关系、工作模式、工作环境等），逐步会很迷茫及焦虑。首先有这种情绪其实很失常，走出舒服区适应新的环境自身就须要很大的勇气，但不必放大这种情绪。次要是要想分明你来这家公司这个团队是为了什么。总之要明确本身的诉求，而后上下左右看看团队在做什么，团队须要你做什么，你能为团队做什么，给本人定位。 2 根本素养 作为技术工程师肯定要有最根本谋求及素养，这些货色决定了你将来的上限，蕴含：自驱学习、谋求极致、匠心文化、一杆到底、ownership精力等。这里不一一开展，网上也有很多的介绍和阐明。《浪潮之巅》中说过：一流的工程师能顶得上10个二流的工程师，一流的工程师天生充斥了责任感和好奇心，他们大都满怀信心但不耻下可，他们间接但不粗鲁，他们不推诿，他们不在乎工作边界，以团队而不是本人的工作工作为指标。 3 成长门路 登上山峰的路线不止一条，这里次要说下点线面的成长门路。当你负责一个很小模块的时候，整个我的项目或者零碎的设计及思路你有没有思考过；当你负责一个零碎的时候，全链路架构的设计及思路你有没有思考过；当你做一个整体架构方案设计的时候，有没有思考到ROI，有没有理解过其余架构域是不是有类似的问题。当你缓缓具备这些能力及意识后，祝贺你曾经变强了，也有可能变秃了。当然也有可能你曾经具备了这些能力，但没有赏识你的伯乐，所以要把握住每一次机会，把一些小的事件做到极致。如果还是没有伯乐发现你的能力，适当做出调整也是不错的抉择。 4 定义问题 面试过很多同学，也帮忙过一些同学做过外部降职简略辅导，很多同学会上来就说我的计划是什么样的，如何如何牛，具体细节是什么。然而站在其他人的角度，他是没有上下文的，压根就不晓得你要解决的问题是什么，推导逻辑是什么，缺失了这些货色，是很难评判你这个计划的好坏，以及这个计划是不是真的解决了问题。所以晓得怎么做很重要，但定义问题更重要，而后是你的思路及推导过程。这也是降职场上常听到的，要思考问题背地的WHY及WHAT。定义问题不是随便扣帽子，当你成为主管的时候，你就是团队的指明灯，要联合业务需要及趋势依据本人架构域个性来剖析和定义问题。 5 向上治理 集体感觉向上治理并不是一个贬义词，很多时候你在闷头做事件，如果不常常和主管对焦，有可能你了解的货色和他所想的齐全背道而驰。在执行及落地的过程中多沟通、多对焦，换位思考，你作为主管喜爱什么样的同学。当然过犹不及，还是要有高质量的对话和输出，不是轻易想到一点货色就找主管沟通和反馈。当你作为一个主管时，也要常常和上面的同学进行one on one，多听听团队同学的想法，给到团队同学沟通对话的机会。 6 独立思考 网络社会，咱们会被动或被动获取到各种信息及常识，须要你兼听则明，就像下面自我认知中说到的，肯定要分明地晓得本人想要的货色是什么。不要听风就是雨，被他人带偏了本人的成长门路。技术上的思考也是如此，下面说的定义问题也是对于要解决问题的思考，另外很多同学在做技术计划时，被他人略微挑战一下就立马慌的不行，其中次要问题还是本人对要解决的问题或景象有没有粗浅地思考，本人有没有很笃定。 7 总结积淀 总结积淀肯定要做在日常，无论是PPT或者笔记，这些总结积淀不肯定非要是技术上的架构思路，也能够是本人的一些想法及感悟心得。一些同学在给他人介绍本人的想法或技术计划时，说了很多内容然而齐全没有重点，抓不住问题的实质。次要是因为两方面，一方面是你本人没有真正思考过，另外一方面就是思考过后并没有造成无效总结。 8 躬身入局 一些同学思路很跳跃，有很多的想法，总喜爱指点江山，感觉这个方案设计不行，那个代码写的有问题。但真正让他去解决的时候，才发现其实很多问题不能只看外表，躬身入局后才会发现很多细节。不是说有想法，喜爱指点江山不好，而是有没有认真思考过，这个问题在特定的背景下换成你去解决，能不能给出更牛的解决方案。另外躬身入局后不能陷入细节不能自拔，很多同学做技术计划的时候，思路会特地发散，感觉这样搞不太正当，那样搞如同也不行，始终犹犹豫豫。特地喜爱一位同学的内网签名：想的都是问题，做才是答案。 9 软性技能 下面说了根本素养决定了你的上限，那对于大部分普通人来说，软性技能决定了你的下限。软性技能包含但不限于：PPT、演讲的能力、情商等。咱们大部分人不是蠢才，在公司外面还是要与很多团队很多人去合作。记得过后做一个架构命题时，听到一位大佬开玩笑说：跨部门合作不肯定齐全是技术边界问题，很多时候你请对方吃个饭，互通下实在的想法，说不定问题就解决了。这里额定多说一点，沟通的技巧——同理心，很多同学在沟通的时候，不论对象是谁，都是一个思路和语调。其实在面对不同的角色，你要站在对方的角度去思考，怎么让他能更承受你的计划和想法。 10 知行合一 明确很多情理和事件很重要，就像你看了这篇文章，也感觉说的有肯定的情理，然而本人没做出啥扭转，那其实等于没看。懂得很多大道理，却仍然过不好这毕生，也说的是同样的问题。阳明心学中始终强调的是知行合一，要把本人的认知和口头联合起来，知中有行，行中有知。 结语工作只是生存的一部分，多抽点工夫健健身和读读书，多抽点工夫陪陪家里人，let's relax。最初举荐几本非技术书籍：《金字塔原理：思考、表白和解决问题的逻辑》、《麦肯锡教我的思考武器》、《思维的实质》、《精进：如何成为一个很厉害的人》、《高效能人士的七个习惯》、《邓小平时代》。 原文链接本文为阿里云原创内容，未经容许不得转载。

简介： 据心理学考察，在人们感到最恐怖的事件里，死亡排名第二，而“公开演讲”排名第一！那么作为一个演讲新人，为了能够不丢人的做好演讲，都须要做哪些筹备呢？ 作者 | 竹涧起源 | 阿里技术公众号 前言据心理学考察，在人们感到最恐怖的事件里，死亡排名第二，而“公开演讲”排名第一！ 上周末去深圳加入了GOPS大会，代表团队分享了弹性计算在SRE体系建设的一些摸索和实践经验。尽管已经屡次给阿里外部的兄弟团队以及一些内部的客户做过相似分享，站在行业的大会上公开演讲还是第一次。作为一个演讲新人，为了能够不丢人的把这场演讲做好，前后花了大略5天工夫来筹备，从选题、PPT制作、演讲稿编写、自我练习，外部试讲以及正式演讲前的各种筹备，整个过程学到了一些常识，所以抽时间简略写写，心愿能够对演讲新人有所帮忙。 本文将从新人首次演讲的筹备全过程视角来分享一下，作为技术人，如何做好一场技术演讲。笔者通过这次演讲总结了一个“技术演讲筹备六步法”，即演讲前筹备-> PPT筹备-> 演讲稿筹备->刻意练习->正式演讲->Q&A，冀望能够通过分享帮忙一些技术同学，尤其是像笔者一样的演讲新人，从零开始筹备并实现一场公众技术演讲。下文将会依照六步法程序进行讲述，倡议按程序浏览，当然对局部内容感兴趣的也能够间接跳到对应章节。 一 演讲前筹备凡事预则立，不预则废。在正式演讲筹备前，对演讲这件事以及演讲的主体，进行肯定理解是不可或缺的。 1 认知演讲缓和是失常的 首先要意识到缓和是失常的，缓和并不是演讲新人的特质。其实，大家熟知的一些演讲蠢才家像乔布斯，以及TED的十分多的出名演讲者都曾走漏过他们面对演讲也会缓和。当然，咱们面对的场景比方规模、受众人群与这些优良的演讲者自不可相比，不过面对演讲时的缓和与恐怖情绪是大家共有的。 那么如何正确认识缓和的情绪？首先，咱们要意识到，人人都会缓和，我并不是特例。其次，咱们要做的是充沛的筹备与一直的刻意练习。当咱们对自我以及受众能够做到知己解彼，对于演讲的内容能够做到庖丁解牛的水平，此刻缓和与否曾经不重要了，因为它并不会对你的演讲产生实质上的影响。 充分认识演讲的目标 其次，咱们要意识到演讲的目标是什么？是为了布道，推广技术还是“带货”？以及为啥要我来演讲，整个过程其实就是“知己”。因为后续无论是PPT制作，演讲稿筹备以及刻意练习的前提都须要先充分认识演讲的目标，以终为始，能力事倍功半。 实在的表白好过低级炫技 最初，不是任何人都能够炫技，低级的炫技成果会恰得其反，这里的炫技包含但不限于： 精（花）美（里）绝（胡）伦（哨）的PPT精心设计的打扮与动作精心筹备的梗...当然这里并不是说PPT要丑，着装要随便，讲述要平白，而是想要表白：如何把想要表白的目标思维，通过实在、天然、柔和（润物细无声）的形式传播给观众，并引发共鸣与思考（高阶需要），这个才是演讲的重点。 2 知己，理解本人后面讲到理解演讲目标是一个知己的过程，其实我了解的知己包含“人”和“事”两局部，其中“事”就指演讲目标，就是咱们演讲时为了实现一件怎么的事件；而对于“人”呢，我感觉是要充分认识本人，比方： 适宜什么样的演讲格调？不必自觉学习他人，寻找本人感觉难受的演讲格调，如果本人都感觉顺当，传达到观众成果自不必说。笔者在筹备期间也看了大量的演讲视频，最初深深领悟到他人的闪亮之处是你学不来的。 在演讲方面的劣势是什么？劣势又是什么？如何取长补短？这里为什么不说补短而要避短呢，我感觉能够把劣势施展到最大水平，而又能够把劣势做到不那么致命，是一件性价比更高的事件。 3 解彼，理解受众知己解彼，如果说意识演讲目标与自我是“知己”，那么，理解观众就是一个解彼的过程。情理其实很简略，观众才是演讲的配角，演讲者本身并不是！演讲的目标就是将主题传递给观众，演讲者只是一个载体，所以充沛理解观众是演讲胜利的前提，也是第一个外围步骤，通常咱们理解观众如下几个方面： 观众群体散布，理解观众的群体分类，以及业余水平，比方这次加入GOPS大会分享SRE的主题确定后，我会先理解今年加入GOPS大会的都是哪些人员，是开发比例多还是运维比例多？是一二线公司比拟多还是小公司比拟多？诸如此类。 感兴趣的话题，在理解观众群体的根底下，能够接着深入分析理解一下不同分层的观众的关注点别离是什么？还是以笔者此次分享为例，在大略理解到参会者的公司分层以及角色占比后，我在演讲内容中会倾向性讲一些和观众非亲非故的痛点，实质上还是为了和观众产生共情，同时能够以观众比拟容易接受的形式传递主题相干信息。 观众受害点，说白了就是大家看完你的演讲，能够播种到什么，比方笔者冀望通过分享能够让大家理解研发团队如何自建SRE体系，以及建设SRE体系通常须要做哪些档次的事件等，这些就是观众的受害点。 二 PPT筹备实用于Keynote或者其余相似工具，因为GOPS大会本次仅提供了PPT模版，笔者下文举例都会以PPT为例。通常技术演讲的模式是比拟固定的，所以PPT内容的outline相对来说也有肯定套路的，下文以我在GOPS大会分享的PPT为样例，做一个介绍。 1 PPT outlineWho 自我介绍局部，倡议1页PPT，简略介绍我是谁，我做过什么，外围在于和观众建立联系，并传播为啥我有资格能够讲这个Topic。 What 倡议一页PPT，通过最简略语言讲述明天要分享的主题，能够让观众通过一句话理解到你要讲的是什么（分享演讲主题的骨架也是一个不错的形式）。 Why 1-2页PPT，重点局部，须要在短篇幅内讲清楚演讲主题的背景，吸引观众的注意力以及引发共鸣。 How 外围演讲内容，通常管制在5-10页，倡议开展3-5个点讲，每个点1-2页。每个点表白上要体现出逻辑性和层次性，通常每一个点要有故事能够讲进去，背景-案例-挑战-解法-成绩。 Future 可选局部，倡议1页PPT，外围表白的是演讲者对演讲波及核心技术将来的认识。通常作为技术类演讲，受众通常为技术类人员，不止关怀演讲者想表白的技术现状，对于演讲者对于指标内容的将来认识也通常比较关心。比方笔者这次分享的SRE局部，受众通常是运维人员，大家在理解弹性计算SRE做了些什么的时候，通常也会关怀咱们将来会做什么？咱们对技术方向的判断是什么？ Recap 结尾总结，倡议应用1页PPT汇总，同时突出重点（重点内容字体要足够大，大到醒目）。通常的技术演讲工夫会在30分钟以上，当演讲进行到序幕的时候，观众能够记住的内容曾经非常少了。而结尾时刻的内容也是受众者比拟关注的，这个时候演讲者来一段提纲挈领的总结，能够无效帮忙大家造成对演讲Topic的整体脉络记忆，同时这个时候肯定要把会议想要表白的核心思想表达出来，再次强化。 2 设计准则PPT设计是一个技术活儿，从内容设计到软件应用，每一个局部都有大量的常识值得学习。在这里我想和大家分享的并不是如何设计PPT（如果大家感兴趣，再抽时间把我无限的PPT技能做个总结），而是PPT设计的一些根本准则。只有遵循这些根本准则，不须要懂任何PPT软件（PowerPoint、Keynote等）的高级技巧，也不须要懂内容编排就能够做进去一个简洁的PPT来满足绝大部分日常场景。大家可能留神到TED演讲以及一些出名的演讲者所出现给观众的PPT，鲜有精美绝伦，更多的是简洁而不简略，内容（PPT内容以及演讲者讲述的）才是重点！ 放弃格调简洁 字号肯定不要超过5种，通常状况不要超过3种：色彩不超过3种不必刻意抉择动画放弃格调对立 抉择一种字体雷同作用的文字或者图片，应用雷同的格局图片格调对立管制内容总量 PPT页数通常不超过30页，核心内容页不超过20页每页文字内容少于篇幅1/2PPT不是重点 PPT永远不是重点，内容才是！不要适度雕饰PPT三 演讲稿筹备当PPT筹备好了之后，大部分同学可能感觉，演讲的素材曾经有了，是不是能够间接“躺平”了。显然不是，那些大家所知的十分职业的演讲比方乔布斯在苹果发布会以及在斯坦福上的演讲，咱们能看到的Keynote只是老爷子演讲筹备中，最简略的一环，此外业余的演讲稿筹备以及大量的刻意练习缺一不可，下文将逐个进行讲述，首先介绍一下演讲稿筹备。 1 是否须要筹备演讲稿首先，大家可能会纠结于要不要写正式的演讲稿？笔者已经也纠结过这个问题，之前的外部分享都习惯了临场发挥，所以在外部第一次试讲的时候，发现自己讲进去的内容的逻辑性以及连贯性都不太好，甚至还不如观众间接看PPT来的畅快。简略复盘下来，最基本的起因之一是因为临场的语言组织能力会强依赖不可控的因素比方环境（受众变动，地点变动等），自我情绪状态（缓和），而无效的解决办法就是备稿并继续刻意练习。 所以，我感觉通常状况，尤其是作为演讲新人来讲，演讲稿筹备是十分必要且重要的一个环节，那么如何筹备演讲稿呢，上面系统性的介绍一下我的思路。 2 如何筹备演讲稿演讲稿肯定是源于PPT的，PPT是观众最直观能够触达的，演讲也是围绕PPT来进行的，所以演讲稿首先肯定是源PPT的，然而如果演讲稿一味和PPT统一，那么演讲也就失去了意义，间接看PPT不是来的更间接，高效吗？ 所以，我了解现实的演讲稿应该是源于PPT，但超脱于PPT。简略解释一下，PPT是演讲的骨骼，而演讲稿应该是血肉，演讲稿存在的价值是让演讲变成“血肉之躯”，而演讲者自身依靠于此，并赋予其灵魂。上面，分享一下我的演讲稿筹备过程。 PPT分组 - 思路分层 ...

6 月 12 日，由声网Agora 与环信联结主办的“RTE 2021 编程挑战赛”圆满闭幕。从 200+ 支参赛队伍中冲出重围的 46 支决赛队伍用精彩的问难为历时 2 个多月的大赛划下了圆满的句号。 往年的“RTE 2021 翻新编程挑战赛”共分为 2 个赛道：利用翻新赛道连续了「应用声网Agora SDK 开发利用」的赛题；技术创新赛道开发者能够「利用声网云市场插件接口，开发自研插件与性能演示 Demo」。 只管此次的赛制与赛题对参赛队伍提出了更高的要求，但同时也为大家提供了独有的技术创新空间。相较去年而言，两个赛道的报名队伍及提交作品简直都是去年的两倍。 本次大赛的决赛和颁奖都是通过 Agora Video Call App 在线上进行的，全程通过 B 站进行了直播。 最终，决赛共诞生了利用翻新赛道的一、二、三等奖团队各一名，“环信专项奖”一名，以及“优秀奖” 六名；技术创新赛道“技术创新专项奖”一名，“优秀奖”一名。 利用翻新赛道一等奖：Agora Home AI随着智能设施性能晋升和网络的疾速倒退，以音视频为根底的智能硬件也正在蓬勃发展中。跨品牌、跨产品的设施治理也成为萦绕在用户日常应用中绕不开的一个话题。 「Agora Home AI」 零碎以智能家居为主题，应用云信令 SDK 实现了IoT 设施近程管制。同时，通过声网Agora RTC SDK 实现人与机器的 1V1 视频，将机器人端采集到的视频发送至 PC 控制中心，进行 AI 智能检测，触发事件响应。 零碎采纳开源了 Yolo V3 算法进行各种视频数据的解决，反对 C#、C++ 调用；Unity 3D、VS 系列开发。目前已反对 Yolo 根底 80 种物体辨认、安全帽辨认、冰球辨认文件等。采纳声网提供的云信令 SDK 进行近程设施管制，构建群组房间进行音讯实时通信，反对通过自定义协定进行智能硬件的管制。 「Agora Home AI」能够帮忙用户实现可穿戴设施、智能家具设施、视频监控设施接入何管制。包含智能灯光、智能门窗、智能门锁、智能安防、智能手环监测、智能家电管制等配套产品，让用户实现多种品牌的智能设施在对立的交互平台内互联互通、对立治理、智能联动。为给用户发明更舒服、更平安、更节能的家居生活环境。 二等奖：Agora FIow取得第二名的作品「Agora Flow」是一个基于声网+环信 SDK 搭建的音视频 Low Code Web 共享编辑器。 ...

简介：本文将介绍问题钻研背景及解决问题的个别法则和非凡法则及二者之间的辩证关系。作者：贺迷信 往期技术一号位方法论系列文章： 「技术人生」专题第1篇：什么是技术一号位？「技术人生」第2篇：学会剖析事物的实质 一、背景1. 从事物的实质说起事物本质就是外部的主要矛盾次要矛盾的演变过程，同时该演变过程受外界环境其余事物的互相关联和相互影响。在广泛的状况下，一个事物的生命周期，是它的主要矛盾、次要矛盾被解决的过程体现。如何剖析问题实质，咱们曾经在《技术一号位的方法论【实践篇】—— 事物本质剖析的操作步骤及剖析事物本质的必要性》 一文中给出了剖析过程和模板，感兴趣的同学能够应用这个模板疏导本人剖析本人的业务。 咱们日常生活、工作中遇到问题都是先从主要矛盾动手，解决了主要矛盾、次要矛盾，随着事物倒退到新的阶段，新的主次矛盾也会持续呈现。当然新的主次矛盾并非凭空出现，而是过来的其余矛盾演变而来，在事物以后生命周期所处阶段，在问题所处的范畴内，成为了妨碍事物持续倒退的主要矛盾次要矛盾。这就形成了事物的倒退过程，事物的倒退过程恪守了这一法则。 如上图所示，当咱们面对复杂事物时，最开始只能感知到以后事物和本人关联最严密的某个方面，即该事物的某个维度。从这个维度动手，解决最外围的问题，即主要矛盾。随着精力和资源的一直投入，当主要矛盾的次要方面、次要方面被逐渐解决，新的主要矛盾呈现，事物倒退会进入下一阶段，如下图所示，事物在某一维度上的纵向倒退，实际上就是一个问题的粒度一直细化的过程，也是生产力对事物的革新不断深入的过程。这一点通知咱们，须要深刻地而不是外表地看问题。 而当事物纵向倒退的同时，随着纵向问题的一直解决，横向的新的维度也会逐渐成为该复杂事物的主要矛盾次要矛盾，如下图所示，事物在横向发展上被感知和解决的维度变多，人们对事物的认知从繁多维度向多维度转变。这个过程通知咱们，须要全面地而不是全面的看问题。 当咱们看到了事物在某一个维度上的纵向倒退的过程，以及事物在多个维度上的横向发展的过程之后，要意识到这两个过程并不是某个过程先于另外一个过程产生的，更多是同时产生的，两个过程的联合并且一直演进各自的倒退过程才是事物自身倒退的法则，最终咱们能够从下图看到一个事物通过若干个阶段的倒退造成的全貌。这一点通知咱们，须要系统地而不是零散地看问题，同时还要以倒退的眼光看问题，而不能动态地看问题。 以上的内容都是围绕事物外在来看它的倒退过程的，联合事物本质的剖析一文来做剖析，咱们还须要看到事外部环境中的其余事物与以后事物的互相关联和相互影响。这一点也通知咱们，要广泛分割地而不是繁多孤立地看问题。 综合后面的图示和阐明来看，深刻地看问题，就是要看到事物倒退过程的细节，各维度下的畛域的细节，这是宏观的视角；全面地看问题，就是要看到更多维度，是宏观的视角；这个过程实际上是从宏观到宏观的视角切换的过程。 要系统化地看问题而不是零散地看问题，就是在视角从宏观切换到宏观的过程中，关注点要从部分切换到整体，从而以全局视角来对待问题； 要广泛分割地而不是繁多全面地看问题，就是要看到外部环境与事物外部主次矛盾的关系和相互影响，既向内看到本身外部的决定性因素，又向外辩证地对待环境对内的影响以及外在对外在的影响和反馈。这个过程其实就是从外向外的视角切换的过程。 要以倒退地眼光看问题而不是动态地看问题，就是不管在以宏观视角还是以宏观视角看问题时，都须要同时在工夫维度上看这个问题的过来是什么样的、当初是什么样、过来是如何演变为当初的、将来可能会变成什么样； 面对简单的问题时，咱们只有从这些角度理清问题的实质，能力在解决问题时，抓住实质和重点。 所以解决问题的过程其实就是：问题的解决由主到次，由骨干到细节，随着该过程的一直迭代，须要被解决的粒度变细，问题须要被解决的维度变多。失常状况下，所有的问题的解决，都合乎这个法则，体现了解决问题的形式的普遍性。 2. 什么是法则在探讨事物的实质的时候，咱们提到了事物倒退是听从一个法则的，然而理解法则对于理论解决问题有什么用途？技术一号位为什么要理解解决问题的法则？做技术和做业务有什么法则可循么？ 在答复这些问题之前，咱们首先要一起看下到底什么是法则，马克思主义哲学的角度是怎么剖析法则的，法则具备哪些个性。以下内容全副皆为从《马克思主义哲学原理》（陈先达、杨耕著） 教材中摘抄的要害内容，受限于文章篇幅，局部内容应用省略号省略，比拟关注的读者能够查看原文来更加全面、系统地了解什么是法则： 法则是实质的、必然的和稳固的分割 • 法则的外延 首先法则是事物及其倒退过程中的实质的分割。事物之间存在着广泛的分割，但并不是所有的分割都是实质分割，都形成法则。…… 这就是说，法则不是事物的景象，而是属于事物本质档次的货色；法则不是通过感官能够间接把握的，规律性的意识属于感性思维档次的意识。 其次，法则是事物及其倒退过程中的必然的分割。法则和必然是等同水平的概念，代表着事物倒退过程中必然如此，确定不移的趋势。所谓法则的偶然性，就是指法则的存在、法则的作用及其结果的不可避免性。具体来说，一些事物的存在，不可避免地会引起另一些事物的呈现；事物倒退的这一阶段，不可避免地要把事物疏导到另一阶段。…… 在事实中，法则的偶然性并不意味着法则只有一种表现形式，也不意味着法则只能以一种形式实现进去。在了解法则的偶然性时，要留神把法则的偶然性与法则的实现形式做适当的区别。 最初，法则是事物及其倒退过程中的稳固的分割。所谓稳固的分割，是指只有具备肯定的条件，法则就会重复起作用，广泛地实现进去。法则的偶然性正是在法则的重复性、普遍性中得以体现的。…… 因而法则的重复性是在一个一个不可反复的事物中体现进去，法则的重复性只是反复贯通同类事物中的偶然性的内容。用事物的不可重复性来否定法则的重复性，实际上是混同了法则的重复性与事物的重复性的区别。 法则的实质不是全演绎，而是对事物本质的把握。在个别之中存在个别，无限之中蕴含着有限。在肯定的事物或流动中证实了规律性，也就是在有限的同类事物中证实了法则的重复性。 任何法则都是主观的，不以人们的用意和欲望而存在并产生作用，既不能人为发明，也不能人为毁灭。法则既不能人为发明也不能人为毁灭，并不意味着在历史上产生作用的所有法则都永远起作用。 任何法则都是在肯定条件下起作用的（这句话极其重要，是本文前面探讨个别法则和非凡法则的转换过程的根底）。法则既不能人为发明也不能人为覆灭，也不意味着人在法则背后无能为力。人们能够通过扭转、发明法则产生作用的具体的条件而扭转法则产生作用的模式。 • 法则的类型 依据法则存在畛域的不同，能够把法则划分为自然规律、历史法则和思维法则。 依据法则发挥作用范畴的不同，能够把法则划分为个别法则和非凡法则。所谓个别法则，就是对肯定畛域内所有事物都起作用，对倒退的全过程都起作用的法则。非凡法则则是对该畛域内某些事物起作用，对该倒退过程的某些阶段起作用的法则。 个别法则和非凡法则之所以有作用范畴大小的区别，本源在于个别法则和非凡法则产生作用所须要的条件不同。一般来说，在肯定质的零碎中，个别法则之所以能对该零碎所有的事物及其倒退的全过程都起作用，是因为个别法则产生作用所须要的条件比拟个别，比拟少，而非凡法则产生作用所须要的条件比个别法则产生作用所须要的条件更多，更具体。从法则产生作用的条件看，法则的普遍性共同性水平是通法则产生作用所须要条件的数量成反比的。法则作用的普遍性水平越高，它发挥作用所须要的条件越少；法则作用的普遍性水平越低，它发挥作用所须要的条件就越多。 对立统一法则是辩证法的本质和外围 （该局部内容与本文主题无关，仅用于科普的目标放进去） 唯物辩证法的法则体系就是由 对立统一法则、质变量变法则和否定之否定法则这三个基本规律，以及内容与模式、实质与景象、起因与后果、必然与偶尔、事实与可能等一系列领域所形成的。其中，对立统一法则形成了辩证法的本质和外围。 3. 为什么要钻研法则钻研法则的目标，是为了迷信地、捕风捉影地、正确地解决日常生产生存中遇到的问题，防止因为不合乎客观规律而带来损失。在日常工作中，往往会遇到看起来非常复杂的场面，如果咱们不把问题剖析分明，不寻找暗藏在问题景象背地的法则，在解决问题的过程中生吞活剥过来的一些教训或者书本上的常识，那么就很可能会呈现经验主义，也会呈现实践偏离理论的教条主义。教训也好，常识也罢，都须要基于事实为根底，不违反事物倒退的客观规律，否则就会被法则反过来教训，付出额定的代价。所以钻研法则有益于止损。简而言之，人们能够“通过做事符合规律”来躲避失败的危险。 钻研法则的目标，是为了找出问题所合乎的法则，而后联合法则产生作用所须要的条件，通过肯定的生产力伎俩来发明该条件，从而利用法则的发展趋势来疏导事物的倒退从而达到咱们冀望的目标。在日常工作中，特地是做业务，对于技术一号位而言，如果只能埋头做本人手中的需要，而不理解业务倒退的法则，那么就无奈在适当的工夫投入适当的兵力做适当的事件。这种状况下，技术一号位实际上变成了仅仅带着一个团队做需要的“包工头”，而不是能够帮助业务一号位实现推动业务倒退重任的技术一号位。 在之前的文章中咱们提到过技术一号位的职责是什么，其中，在零碎架构方面，零碎架构的前瞻性、可扩展性的前提就是可能把握业务倒退法则而提前做了技术架构上的布局；除此之外，在兵力的投入、战斗的发动等组织协同方面也都须要合乎业务倒退法则。如果不论业务以后阶段的问题和主次矛盾，也不论这个主次矛盾将来会朝什么方向倒退，那么最终技术只能被动地响应业务需要，被业务需要推动倒退。 如果提需要的人把握了业务倒退法则还好，一旦提需要的人眼里也只能看到客户抛出来的问题而不是业务发展趋势和法则，那么可想而知技术的投入本质上是在围绕着细枝末节做无用功。而对于那些有能力的技术一号位，做的各种技术决策不仅能撑持业务的倒退，保障业务的运行，更重要的是利用生产力的晋升，联合业务倒退的法则来疏导、驱动业务的倒退。咱们明天不聊具体某个事件怎么做，如果有同学想探讨个例，咱们能够线下交换。须要大家明确的是，每个业务所处环境不一样，每个业务所处的倒退阶段不一样，所以讲再多的个例都没有意义。咱们要间接从不同个例中的共性讲起，讲透，找到法则，这样就能让更多的人做业务的时候晓得当初要做什么，为什么要这样做，接下来要做什么。简而言之，就是通过“预测事物倒退法则”，依附法则来从事物倒退中获益。 钻研法则的目标，也是为了利用个别法则和非凡法则的辩证关系，把握突破法则的能力，从而让看起来不可能、不符合规律的事件产生，从而从中受害。“看起来不可能、不符合规律”的事件，可能是减速事物某个阶段的倒退，也可能是间接跳过事物的某个倒退阶段间接进入下一阶段，还可能是缩短了某个事物在某个阶段的停留。总之，在结构性上影响事物的倒退，要比单纯地利用法则或抗拒法则获益更大，当然影响也更粗浅。 比方做业务的过程中，咱们能够利用已有的中间件和零碎服务来升高业务启动过程中的技术投入从而减速业务启动过程；咱们能够利用已有的根底保障机制和零碎工具来升高业务倒退过程中的系统性危险，从而可能把兵力聚焦在业务问题的解决上，从而可能跳过反复的稳定性建设的阶段，减速业务倒退过程；原来一个业务要必然经验的生命周期的各个阶段，都随着相干技术的复用和生产力的晋升而在工夫上被压缩或间接跳过，因而业务倒退速度要比单纯堆人力要更快。 所以“业务倒退恪守其生命周期”这一非凡法则，被突破的时候，就能让业务跳过某些看起来是必须的无奈跳过的环节。简而言之，就是通过“突破法则”，来发明看起来的不可能。咱们须要辩证地了解“看起来不可能”。看起来不可能本质上是产生了“在某人或某些群体认知之外的” 的事件，在具备更高的生产力的群体来看，前者眼里的不可能大概率是稀松平时的事件，举个简略的例子：飞机对于原始部落和现代文明而言，别离是“不可能”和“平常事”，实质上问题不在于飞机，而在于不同群体所把握的生产力的差别。对于认为“不可能”的群体，让他们突破既有认知法则的最简略的形式就是把更先进的跨代的生产力赋予对方。 二、解决问题的个别法则和非凡法则及二者之间的辩证关系1. 为什么要剖析解决问题的法则咱们日常生产生存中，很多事件，最初实质上都能够形象为在解决问题，只不过问题所属的畛域不同，背景不同，波及的方面不同，问题所处的环境和倒退阶段也不同，尽管变幻无穷，即事物自身存在特殊性，然而在如何解决问题上，也是有个别法则和非凡法则存在的，也是合乎矛盾的普遍性的。因而把解决问题的法则钻研分明，剖析分明解决问题的个别法则和非凡法则之间的辩证关系，对咱们日常工作和生存有极大的益处，或者说，对于技术一号位来讲，有助于做好日常工作，履行好角色赋予的职责。 2. 为什么要剖析个别法则和非凡法则之间的辩证关系在下面的剖析中咱们能够看到，钻研法则的最高境界是突破法则，而突破法则须要了解个别法则和非凡法则之间的辩证关系。 如果只是单纯地、抽象地探讨这个个别法则，那么对于咱们理论生产生存中解决问题的指导意义太弱，而如果不探讨这个解决问题的最根本的个别法则，那么再探讨更具体的场景时，非凡的法则是如何来的，非凡法则如何被突破，就说不清了。所以二者之间的辩证关系是咱们最高效地利用法则的实践根底。 咱们上文中援用了《马克思主义哲学原理》教材中的一段话，这段话是对于个别法则和非凡法则的关系的。然而从探讨能够看出，教材只简略地提到了个别法则和非凡法则的差异，并没有探讨二者之间的关联性。在这里咱们尝试来剖析一下二者之间的关联性，剖析分明二者之间的辩证关系，从而可能让咱们从中获益，疏导咱们看清在日常做业务、做技术的过程中，看明确个别法则是什么，非凡法则是什么，如何利用个别法则来“突破”非凡法则，或者利用非凡法则来突破个别法则，从而可能让事物倒退的过程受咱们的疏导。“突破法则”看起来和“做事件要合乎客观规律”是矛盾的，但“突破法则”本质是指扭转事物符合规律的条件，从而让事物合乎新的法则；而“做事件要合乎客观规律”讲的是事物所属环境的条件不论怎么变，都是会听从某一种法则的。因而实质上二者并不矛盾，要辩证地了解这个“突破法则”和“做事件符合规律”的关系。 个别法则和非凡法则之间的辩证关系在接下来的探讨中，咱们会把法则对事物起的作用简化表述为“管制”。这并非学术性的简化，只是单纯为了精简探讨过程，并且把表述口语化。 个别法则和非凡法则之间的辩证关系具体如下： • 在肯定畛域内，个别法则对所有事物起作用，包含该畛域内的合乎某个非凡法则的事物。• 在肯定畛域内，非凡法则管制的事物对外体现为受非凡法则的管制，然而并不意味着个别法则所起的作用不存在。• 在肯定畛域内，非凡法则和个别法则是叠加存在独特施展着作用的，在非凡法则的条件下事物沿着非凡法则的解放倒退，当满足非凡法则的条件隐没时，事物整体的倒退受个别法则管制。• 在肯定畛域内，“构建合乎非凡法则的条件”是决定事物受非凡法则管制还是受个别法则管制的关键因素，而生产力是决定该关键因素的关键因素。 对于个别法则和非凡法则，咱们能够从如上示意图中看到，个别法则的影响范畴大，普遍性高；非凡法则的影响范畴小，普遍性低而特殊性高；同时，非凡法则须要更高的生产力，而个别法则则对生产力的要求不高。同时咱们须要晓得生产力的利用会带来老本，所以个别法则和非凡法则之间的转换也会波及到老本因素，如下图所示： 基于下面的剖析以及示意图能够晓得如下论断：事物受非凡法则影响还是受个别法则影响是能够互相转换的，而让这种转换产生的要害是对该事物操控的生产力的程度。生产力低下的时候，事物在个别法则或者非凡法则之间转换的难度高，事物在所处环境和条件下更偏向于恪守使之产生的法则而不产生所恪守的法则的变动；生产力进步的时候，事物在个别法则或非凡法则之间转换难度随着生产力的进步而变低，事物恪守的法则能够在生产力的帮忙下调整从而容许人间接影响事物倒退法则。因而，当咱们想要利用法则甚至突破法则的时候，咱们能够持续从下面的实践剖析得出如下论断： 在咱们生产力程度比拟低的时候，解决问题要合乎事物的倒退法则；而在生产力程度比拟高的时候，咱们能够通过调整事物合乎非凡法则的条件从而让事物恪守非凡的法则，或者让事物不再恪守非凡法则而回归个别法则的管制；如果咱们想要突破法则让看似不可能的事件产生时，不是仅仅把资源投在事件的自身上，而是同时须要投入在与之相干的生产力的晋升上，二者之间的投入比例须要视理论状况做调整。解决问题的个别法则和非凡法则探讨完个别法则和非凡法则的辩证关系，咱们终于能够探讨解决问题的个别法则和非凡法则了。 在背景章节中咱们从事物的实质引申到了问题解决的法则，即：解决问题的过程合乎事物的实质演变过程，“由主到次，由骨干到细节”，周而复始，直至事物沦亡。依照马克思主义哲学原理中法则的类型的划分来看，这个法则应该属于个别法则，而不是非凡法则，因为除去极个别的状况下，大多数人都能在解决问题的过程中抓住重点去解决，即使这个人并不理解马克思主义哲学，不相熟矛盾论，这个法则须要的的条件不多，适用范围极广，所以它是个别法则。 ...

简介：对于研发同学而言，探索事物的实质，是最根底最外围最先须要被把握的技能，没有之一。作者：贺迷信 技术一号位不是岗位，更多的是技术人员在公司中做事的一种心态，这个系列的文章适宜所有想要对日常工作“知其然更知其所以然”的技术人，借助实践工具的指引，联合本人的实际经验，悟到本人的播种，从而减速成长的过程。大道理千千万万，有缘者得之真谛践于其行而非流于其表。 将来一段时间，阿里巴巴中间件公众号会继续公布系列文章，欢送关注。往期技术一号位方法论系列文章：「技术人生」专题第1篇：什么是技术一号位？ 背景生存中每时每刻都在产生着各种各样的事件，有些与己相干，有些看似毫无瓜葛，不管事件大小，总须要分出一部分精力，或多或少，对事件进行解决解决。在解决这些事件的过程中，在和某些人接触时，总能感觉到他们对事物的认知要更粗浅，更全面，听其言如同醍醐灌顶，观其行胜读十年书。这样的人解决问题往往切中时弊，事倍功半；而在和另外一些人沟通时，则可能会感到对方对某个事件的认知其实流于外表，解决问题往往抓不住重点，做的很辛苦却多是无用功。那么到底是什么造成了两种人对事物认知的差别？是否有什么路径或者形式可能打消这种差别？ 作为技术研发人员，总面临着各种各样的需要，总会有前人一直强调技术的复用，强调代码的重构，可是往往是倒排的截止日期逼迫研发更快上线长期需要，造成线上拣不洁净的满地鸡毛，同时留下一身还不完的技术债权。为什么面对肯定会变的业务需要，研发人员仿佛永远跟不上需要变动的节奏？很多时候大家本能的会怪罪产品经理没有想分明，那么有没有人思考过，和咱们每天配合的产品经理或者经营人员，到底是什么货色没想分明，从而导致了咱们研发同学本人一直地返工？他们没想分明的事件，咱们是不是素来就没想过？这些事件，咱们该不该想，能不能想分明，有没有益处？研发人员须要把握什么技能来应答永远都在变动的业务需要？ 作为零碎架构师，在面对简单业务零碎时，开局往往操作猛如虎，三年布局五年演进，可是通过若干年的建设，往往只是遗留下泛滥见招拆招的祖传代码，新的需要须要在旧的业务逻辑的缝隙外面找“解法”，一线开发人员不仅要避开“牵一动员全身”的各种弯弯绕绕，可能连架构自身也曾经变得模糊不清了，更不必提架构的演进。这所有都会逐渐失控上来直到某一天达到临界点再来一次颠覆式的重构，让凌乱从新回到原点，开始新一轮的技术债权周期，当然，零碎肯定是 2.0 或者 3.0了（目前还没见过 4.0 的零碎）。可是当年说好的架构可扩展性呢，说好的形象水平高呢？架构自身到底和业务有什么关系，架构的演进又和业务的倒退有什么关系，如何能力让架构师突破“架构设计和演进过程被事实重复打脸”的魔咒？ 作为研发团队 leader，带着本人的人做需要交付，一边忍住亲自下场写代码的激动不得不做着项目管理的事件，一边又可能被上面的人狐疑技术能力；各种倒排的截止日期好像一条条排着队催债的红线，眼看着这些红线圈着本人团队的黑着眼圈的兄弟，在一个又一个的坑外面像炮灰一样摸爬滚打，而本人只能像一个大号的外包资源经理一样对这种场面在实际行动上大刀阔斧，在思想上除了感觉要一直加人之外感觉无力回天。如何能力让团队成员在做业务的过程中不再是资源一样被耗费而是像资产一样自我增值？如何能力利用对业务发展趋势的预测突破法则提前布局，在策略上把握主动性，从而在战斗上既能先于对手做出稳固的产品，又能有足够的工夫打磨产品从而晋升用户的应用体验？ 不同角色的技术人，不管在工作还是在生活中，面临的这一系列陈词滥调的问题时，或者都心愿能有一抹就灵的万金油，打一发银弹进来，就可能留下广为业内传唱的人月神话。可是在现有的生产力条件下，技术人员既没有万金油，更不存在银弹，而且人月神话永远都是神话。所有的事件，所有的问题，想要被解决，都要回到最后的原点：这件事件的实质是什么？也就是说，咱们日常工作中的事件的终点不是应用什么工具解决问题，而是先认清这件事件 —— 认清一件事件的实质，是所有后续口头的前提和根底。做业务需要剖析也好，做架构设计画架构图也罢，计算机语言和技术栈的抉择以及相干整体解决方案的构建是一方面，而“基于对业务实质的了解进行的业务建模并联合业务倒退继续演进”是极其重要的、却往往被忽视的另外一个方面。 日常工作中，很多研发人员往往把注意力集中在各种计算机语言及其技术栈上，大家会花工夫翻看各种技术书籍，探索各种技术计划背地的原理，而后通过业务实际晋升集体技术能力，所有的促成个人成长的事件简直都是围绕着“技术”两个字开展，然而，特地是对于长年从事业务研发的同学而言，大家是否意识到，除了“技术”以外，还须要把握“业务”相干的常识，而其中，探索事物的实质，是最根底最外围最先须要被把握的技能，没有之一。它是策略层面构建业务大图的根底，是排兵布阵发动要害战斗的根底；也是战术层面剖析业务需要的根底，做架构设计的根底，做业务领域建模的根底。技术一号位须要把握的所有工具和方法论，所有的终点都是它，所有的实践工具和方法论最终都是它在某个畛域内的利用、投射和简化。 什么是事物的实质事物本质的哲学定义抽象地探讨事物的实质，波及到了哲学层面，目前自己不具备相干的能力来进行具体的实践论证，这里就间接摘抄马克思主义哲学对于事物本质和景象的对立统一的阐述，来看哲学层面的事物的实质是什么：• 实质是事物的基本性质，是事物本身组成因素之间绝对稳固的内在联系。—— 《马克思主义哲学原理》（第五版，陈先达、杨耕著）• 实质是事物的基本性质，是事物本身组成因素之间绝对稳固的内在联系，是由事物自身所具备的非凡矛盾形成的。—— 百度百科• 唯物辩证法的宇宙观主张从事物的外部、从一事物对他事物的关系去钻研事物的倒退，即把事物的倒退看做是事物外部的必然的本人的静止，而每一事物的静止都和它的四周其它事物互相联系着和相互影响着。事物倒退的根本原因，不是在事物的内部而是在事物的外部，在于事物外部的矛盾性。任何事物外部都有这种矛盾性，因而引起了事物的静止和倒退。事物外部的这种矛盾性是事物倒退的根本原因，事物和事物的互相联系和相互影响则是事物倒退的第二位的起因。—— 《矛盾论》毛泽东• 钻研问题，忌带主观性、片面性和表面性。所谓主观性，就是不晓得主观地看问题，也就是不晓得用唯物的观点去看问题。这一点，我在《实践论》一文中曾经说过了。所谓片面性，就是不晓得全面地看问题。—— 《矛盾论》毛泽东 事物本质与景象的对立统一剖析1、实质和景象是对立统一关系。任何事物都有实质和景象两个方面。世界上不存在不体现为景象的实质，也没有来到实质而存在的景象。实质和景象是对立的，但二者又有差异和矛盾。实质从整体上规定事物的性质及其根本倒退方向，景象从各个不同侧面体现实质；实质由事物内部矛盾形成，是比拟繁多、稳固、粗浅的货色，靠思维能力把握；景象是丰盛、多变、外表的货色，用感官即能感知。假象从否定方面体现事物的实质，给人一种与事物齐全相同的印象，掩盖着实质。假象的存在显著体现出实质和景象的矛盾。因而不能简略地把景象与实质等同起来。—— 百度百科 2、事物的实质与景象是对立统一的，这是主观辩证法，把这种辩证法使用于人的认知过程，就要求人们既不能脱离景象去空谈事物的实质，也不能停留在事物的景象上，而要透过景象抓住事物的实质。（本文作者批注：透过景象看实质，这句话谁都懂，然而到底怎么能力做到，是本文尝试给出的。） 为此，要在实际的根底上察看大量的景象，尽可能多地占有理性资料，这是认知透过景象抓住实质的前提条件。（本文作者批注：这就是“没有考察就没有发言权”的理论依据。）在察看社会问题时，肯定要学会辨别实质与景象，要抓住实质与支流，这是其一。 其二，有了察看到的大量景象，占有了实在的理性资料，并不等于抓住了事物的实质，要透过景象抓住实质，就必须对大量的景象、实在的理性资料，以及它们之间的关系进行剖析和钻研，这就须要把握迷信的办法。（本文作者批注：《马克思主义哲学原理》中并没有讲明须要把握的迷信的办法到底是什么，而这一点，恰好是本文作者结合实际实践经验尝试给出的，同上一个批注。） 其三，事物的景象盘根错节，而且事物的实质有一个逐步裸露，逐步开展的过程，所以人们对事物本质的认知不是一次实现的，而是一个一直深入的过程，是一个由全面到全面、由不太粗浅到粗浅的过程。—— 《马克思主义哲学原理》（第五版，陈先达、杨耕著）理解了哲学层面的实质与景象的对立统一关系，有的读者可能会问，这和业务研发有什么关系？我这里只举一个看起来十分小然而实际上问题很大的例子：咱们所做的新批发业务，整个流程涵盖了供应商、平台、渠道客户、合作伙伴和消费者这些不同的业务参与方，整个业务能够让供应商入驻平台，给平台上的渠道客户供货，从而让渠道客户本人的用户可能以积分或者积分加现金的形式购买商品。 某天产品经理提了一个需要，说要“在供应商控制台中减少一个删除按钮，删掉供应商不想看到的商品”。看似非常简单的一个需要，在商品列表外面减少一个删除按钮，应该很快就能上线，然而实际上，删除商品这个动作背地真正的业务含意和场景并不是简略的技术上的把商品数据软删除，而是“进行供货”——供应商要删除的商品很大概率曾经签过在线协定，以某个价格供货给某个渠道客户，这个时候研发人员如果依照需要无脑删除商品数据，就会造成曾经在售卖甚至在加入经营流动的商品忽然无奈购买，造成渠道客户的损失或引发舆情。 所以，研发人员沟通完需要要进行技术计划评审时，被我驳回，要求相干的同学实现业务场景的剖析和探讨，补全删除按钮背地的残缺业务流程，将“删除”按钮的名称批改为“进行供货”按钮，并且针对曾经不在任何渠道销售的商品独自提供筛选项，而不再在供应商商品治理列表外面默认展现。所以整个需要本来就是一个删除按钮1天的工作量，实际上剖析分明产品需要背地的业务场景和真正的业务含意当前，就变成了一个波及到了进行供货的在线审批流程、供货协定更新、渠道在售商品下架等等一系列联动的简单业务需要，技术计划的复杂度和原来相比更简单，排期更长。 作为业务的技术负责人，如果不能把握业务需要背地的实质，相似这种状况会层出不穷，所有疾速上线的长期计划最初都要随着需要的深刻而从新投入人力和精力进行重做，这方面的老本往往会转嫁在一线研发同学身上。 探索事物本质的办法形象的哲学定义并不能给咱们提供透过景象看实质的实际操作办法，然而却指明了事物本质的组成和关键点。咱们能够基于哲学上的定义和《矛盾论》全文以及本文中特地援用内容可知，如果想要剖析分明一个事件的实质，就是要主观地去剖析事物，梳理它外在的主要矛盾和次要矛盾，同时须要梳理外在的它和它所处环境内其余事物的互相分割和相互影响。 外在要剖析钻研指标事物的组成部分和对应的对立统一关系，从而得出对应的主要矛盾次要矛盾，理清矛盾的次要方面和次要方面。须要留神的是，相干的剖析是建设在事物的某一维度上，在事物倒退的某一阶段上的，随着事物的倒退，相干的剖析可能会呈现变动。事物的外在决定了事物的实质。如下图所示： 外在要剖析在肯定环境下，钻研指标事物和其余事物之间的互相关联关系和相互影响。事物的外在通过事物的外在关系和影响来影响事物的倒退。这一点能够简略思考一个问题：一把一般的锤子能够突破一面一般的玻璃，根本原因在锤子还是在玻璃？如果感觉根本原因在锤子的读者，能够持续思考：一把一般的锤子能够突破钢化玻璃么，能够突破防弹玻璃么，能够突破钢铁么？如下图所示： 通过以上的示意图和对应的剖析阐明，咱们能够理解到在剖析问题实质的过程中的所有关键因素，对于具体操作步骤和阐明指引，在本文第四章节会给出模板，不便大家在理论工作生存中应用。 剖析事物本质对技术一号位的必要性业务研发，特地是简单业务零碎的研发，实现产品经理提出的业务需要仅仅是其表象，其真正实质外延，是应用技术手段将解决某一特定问题的逻辑数字化，利用计算机技术对客观事物做数字化的建模，以尽可能贴近事物本质的形式进行逻辑和数据的运行，从而实现事实和虚构的映射，解决对应的问题。 作为研发团队的技术负责人，如果对业务的认知的终点是产品经理输入的产品性能文档，对业务的了解来源于源源不断的业务需要，不能认清业务的实质，不能看到将来的一些可能的发展趋势，那么这样的技术负责人其实只能做到了响应业务的需要，永远无奈真正的在技术架构和解决方案上撑持业务的倒退，更遑论应用技术驱动业务倒退了。 这也是“技术一号位” 和 “研发团队 TeamLeader”的最大的区别，前者是业务的共建者，利用技术背景和专业技能辅助业务一号位推动业务的倒退，实质上是在表演决策者的角色，而后者只是研发资源的协调者和我的项目进度的把控者，实质上是在表演执行者的角色。面对非常复杂的事件的时候，咱们须要可能有正当的实践工具来撑持本人，将简单的状况骨干脉络理分明，而后剖析它为什么当初会是这样，过来是什么样的，在什么条件下，将来会倒退成什么样，而后再剖析哪些要害局部是咱们能够通过实际行动影响的，从而通过影响要害局部来疏导事物将来的倒退方向。 以下内容就是面对简单问题的时候，根本的剖析操作流程。 剖析事物本质的操作步骤事物外在剖析1、明确事物探讨的范畴 明确问题探讨的范畴十分重要，同一件事件，在不同的范畴内探讨，得出的论断可能齐全相同，起因并不是咱们应用的实践工具有问题，而是随着探讨范畴的扩充，探讨的事物自身的组成和外界的互相分割和相互影响都会变动，所以就会有不同的，甚至是相同的论断进去。所以为了解决某个固定的问题，咱们首先要确定的就是这个问题的范畴是什么，它所处的环境是什么，探讨的问题的场景是什么。这些是开展所有的剖析的根底，如果多人探讨的状况下，不把这部分内容对齐，就会非常容易导致探讨的时候各方论点驴唇不对马嘴。 2、剖析事物外部组成及其存在模式 在明确好事物的范畴当前，咱们须要剖析分明这个事件中的各个组成部分，每个组成部分是以什么样的模式存在的。 3、剖析事物外部各组成成分所表演的角色及其职责 事物的每个局部，在这个事物中，都表演了某种角色，这个角色是某个局部的职责和行为的形象，所有的行为都体现着该局部的外围利益诉求。 4、剖析各角色在职责限定下的外围利益诉求 在剖析完事务外部各组成的角色当前，接下来就是剖析该事物外部组成在对应角色的要求下的外围利益诉求了。须要留神的是，在探讨外围利益诉求的时候，须要联合场景，明确探讨范畴，否则所很多事物最终的外围利益诉求都会被过渡抽象化，然而很多时候一个问题是一个具体的、有范畴的利益诉求开展的。只泛化地探讨通过形象后的利益诉求，既不不便剖析矛盾点，又不能具体的解决理论问题，所以在探讨对立统一的时候，明确外围利益诉求要限定范畴和场景，不能一味只做形象，只去看矛盾的普遍性而不看矛盾的特殊性。 事物组成 1 • 外围利益诉求讲清楚该事物组成 1 的外围利益诉求是什么• 外围利益诉求的由来剖析讲清楚该事物 1 的外围利益诉求为什么是这样的 事物组成 2 • 外围利益诉求讲清楚该事物组成2的外围利益诉求是什么• 外围利益诉求的由来剖析 ...

前言什么是技术一号位、有哪些关注点、怎么做技术一号位？ 做了研发团队的技术 leader 当前，要解决的事件十分多，如果对本人表演的角色没有一个清晰的认知，就会呈现该做的事件没有做，不该做的事件投入了过多的精力，造成实际行动和后果既不匹配下级的要求，又不匹配上级的冀望。特地是对于刚开始率领研发团队的新人 leader 而言，角色的转换和适应的过程，减少了认清本人的角色实质的难度。明天咱们抛开纯技术团队的同学不谈（其实实质一样），只探讨业务研发团队的同学，如何以技术一号位的角色来做事。 如何辨认本人是不是技术一号位在开始谈如何做事之前，首要任务是判断本人是不是技术一号位，而要判断之前，首先要明确判断规范，跳出思维误区。这里咱们列出一些常见的思维误区。以下是常见认知误区： 带人的是技术一号位，不带人的不是技术一号位。级别高的是技术一号位，级别低的不是技术一号位。以上的认知误区，谬误地把是否带团队、技术等级的高下和是否为技术一号位关联起来。尽管事实上带团队的业务研发同学成为技术一号位的概率更大，然而自身这两者不是划等号的关系。那么什么是辨别是否为技术一号位的决定性因素呢？很简略：对一个具体的业务而言，你作为该业务的间接技术参与者，是否处在技术畛域责任链的最顶端。这句话翻译过去就是，对一个明确的具体的业务而言，多种角色的同学一起单干的时候，你是否是技术序列的最终责任人，即：谁承当对应的责任，谁就应该表演对应的角色。 当产品经理、经营、研发独特做一个业务的时候，某个研发同学单独或者率领其余几个研发同学，或者率领跨 BU 的研发团队，独特撑持 PD 的业务需要。那么这个研发同学就是这个业务的技术一号位，不管他是否带不带人，也不管他带的人在行政上是否从属于他。一般来说，负责繁多业务的研发团队 leader 个别就是这个业务的技术一号位；负责多业务线的研发团队的 leader 的上司，是每个业务线的技术一号位，而研发 leader 自身是更高层面业务的技术一号位。 所以，做业务开发的技术同学，不论是什么层级，带不带人，都可能是某个具体业务的技术一号位的。这一点十分重要，只有认清这个事件当前，业务研发同学能力在做业务的时候，明确下来本人除了须要写代码以外还须要做什么，关注什么；这些关注点须要做到什么水平，能力对上满足冀望，对下不让团队走弯路、不和上司抢功。 当你通过以上判断当前，确定本人是技术一号位时，祝贺你，你曾经不再是一个仅仅须要写代码的研发同学了。很多研发同学眼中还是只有写代码这一件事件，如果以这种形式做业务，那么就会发现业务过程会有各种没有做到位的事件，会在做业务的过程中“交很多学费”，甚至会因为本人的能力不够而拖慢业务倒退。尽管成熟的研发团队能够通过齐备的研发过程治理，来防止集体能力不够而对业务产生太多负面影响，然而实质上强制的规定和“下级要求”只是在依附行政管理手段在强制一个人做这些事件，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。 这些“工作琐事”实质上是须要他表演的角色来负责的，然而因为他没有意识到本人实际上曾经是这样的角色了，而仅仅把本人停留在“研发”的定位上，把“写代码”当做外围工作，这样一来，会让研发同学对那些看起来 “和写代码无关然而是技术一号位必须做的事件” 十分冲突。这种抵触情绪产生的时候，leader 再强调 Ownership 也都没有太多成果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事件。当他的心态和认知转变当前，一些原来看起来不怎么负责的人会变得负责（不排除有人自身就是不负责的人，那么这样的人不是良好的技术一号位的候选人，主管要有辨认能力）。 作为业务开发同学，肯定要认真认清分别本人本质上是不是一个业务的技术一号位，而不必思考本人的层级，不必管本人是不是业务其余参与者的 leader。当你意识到本人是这个业务的技术一号位的时候，就要迅速切换角色，从原来本人给本人的定位 “写代码的、搞技术的” 转变为 “某个业务的技术一号位”，开始进入角色，施展出你的价值。这也是很多研发同学通过做业务能迅速成长的起因，抛开技术上的成长之外，他比其余研发同学接触了很多 “做事件须要思考并为之口头” 的维度，这些维度的丰盛是一般业务研发同学很难看到、很难感觉到，因而更难悟到的。 不排除有悟性高的研发同学可能本人悟到，但实质还是因为他所处的环境、他面临的问题在逼迫他做出思考，而后为之实际。如果一开始就晓得本人做事件要找准本人的角色和定位，那么就会少走很多弯路。 剖析你所在环境的局势当你意识到本人是一个业务的技术一号位的时候，不必过多狐疑本人到底是还是不是，而是要本着“就当本人是”的心态来进行接下来的工作实际和思考。须要大家明确的一点是，任何一个工作角色，都有对应的责任，也都有履行对应责任的方法论。咱们要做的，不能再像过往做一般研发的时候那样懵懵懂懂去做事，听“需要”指挥，而是要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，晓得本人比过来多了哪些维度的事件要关怀，晓得接下来会面临什么样的挑战，要晓得本人在挑战中应该表演什么样的角色，采纳什么样的伎俩去解决业务在不同阶段肯定会呈现的各种问题。 在开始所有的思考之前，先要做一件事件，就是剖析你目前所处的环境的局势。业务方面• 你的大团队的业务大图是什么• 你负责的业务的大图是什么• 你负责的业务大图是否和大团队的业务策略匹配• 你负责的业务和大团队的业务看似没有契合点的时候，你的leader跟你对焦当前的论断是什么• 这个业务对客户的价值是什么• 这个业务对组织的价值是什么• 这个业务对你集体的价值是什么• 这个业务是否会在将来承当社会责任，会有怎么的社会价值• 这个业务目前处于什么阶段，是刚开始，还是曾经成型期待倒退，还是曾经倒退一段时间须要业务规模• 这个业务目前存在最大的问题是什么合作方面• 谁在配合你一起做这个业务• 和你一起做业务的同学中，别离有哪些角色，他们会在哪些方面和你有交加• 和你一起做业务的其余角色的同学，是否对业务大图的了解和你统一• 和你一起做业务的其余角色的同学中，谁是业务的负责人；或者要害角色的人员是否对本人是业务负责人有感知• 业务上下游的同学段位怎么样，是否能在理论落地过程中跟上你的节奏• 业务一号位的KPI是什么，你的KPI是什么，你们两人的KPI是否方向统一，你的KPI是否能撑持他的KPI团队研发方面• 当初是否有一个研发团队反对你一起做这个业务• 和你一起做业务的研发团队是否在行政上从属于你• 你带的团队人员每个人的特点是什么，有什么短板，在这个业务外面负责什么事件• 研发团队外面谁是你的接班人• 研发团队外面谁能补充你的短板• 研发团队外面，每个人做事都有什么集体的想法？集体的成长目标• 研发团队外面的每个人对业务大图是否理解，认知是否统一，指标是否统一如果你自身曾经是专家级别以上了，那么上面这些维度可能是须要你持续深刻思考的： 业务方面 • 业务的愿景是什么• 业务的愿景在不同工夫维度上拆解当前的要害业绩指标是什么• 为了实现不同工夫维度的要害业务指标，你筹备投入什么样的资源？投入的资源之间互相怎么配合？相互配合的准则是什么• 这个业务当初做是否适合？当初做不适合的话，须要在什么时候做适合• 这个业务当初做不适合的状况下，哪些因素让你感觉当初做不适合• 让你感觉当初做这个业务不适合的因素中，哪些因素是能够通过人为干涉让它不再是妨碍性的，哪些是能够通过人为干涉减少它对业务的踊跃作用• 业务的现状及瓶颈问题• 业务问题的技术解法• 业务发展趋势• 业务竞合剖析• 业务倒退策略• 业务的终局畅想 ...

这个问题对于每一个人来说各有各的起因。有的为了写作变现，有的为了本人的趣味，写小说，写文章，写书。 甚至写传记，留下本人在这个世界的点点滴滴。 不管哪一种起因，咱们都违心用写作的形式来表白咱们的思维，咱们的生存，咱们的经验。 在漫漫人成长路中。可能留下一些乏味的文字，让将来的人可能有迹可循。 当然同类做法你也能够用拍视频的形式，让本人生存的点滴可能留在镜头中。 只不过相对来说写作的话更加易于上手，易于开始，能够说是一种低成本的输入形式。 这应该是一种，重要不紧急的事件，是须要打持久战的事件。心愿本人可能用文字的形式始终记录上来。 那么我写作的起因是什么呢？ 我写作的出发点是从去年8月份开始的，因为本人冀望将技术可能晋升一个阶，本人寻找了一些学习形式。 最终落地，在本人的常识肯定要文档化。须要在本人的环境中建一个举世无双的知识库，这是专属于本人的知识库。 当然，若他人须要本人的知识库，也是能够将其分享进去。 因为本人的知识库肯定要做成可能把他人教会的水平，才能够算是一篇。好的文章。 或者说本人对于某一个知识点或技术点，才是真正的了解和明确。 常识文档化本人是做技术的那么肯定要有长期持久战的打算须要长期学习新的货色并且不能囫囵吞枣。 对于本人的学习门路得有一个明确的布局，本人的技术栈要有清晰的认知以及将来的倒退方向须要明确。 对于学习或工作过程中遇到的技术点，本人肯定要将其原理了解明确，本人可能将该技术点讲授给他人听懂。 对于每一个技术点。须要将其写成文章总结成博客的形式收回来。这样的形式有三个长处。 其一是对于本人的常识可能更加的印象粗浅，本人在书写博客的过程中，可能对技术要点理解的更加透彻。 其二是在将来本人又再次遇到同样的技术时，我本人有一些要害细节忘记， 那么能够在翻阅本人的博客文章，可能很快的将该技术细节给捡起来，更快的投入到工作和开发终中。 其三是分享进去的文章，可能让有需要的敌人。看到能够一起学习，一起探讨，一起沟通。 每一个人的认知是不一样的，这基于本人的环境背景精力等等，所以一篇文章大家的认识和感触是不一样的 那么。就可能呈现思维碰撞，可能碰撞出微妙的火花，让更好的更有价值的货色出现进去。 就像写简书的敌人一样，要是有很多读者点赞的话，那么他会在将来输入更多高质量的文章和常识。看到这里的敌人，你们懂我意思吧。 总结技术博客以上是我学习技术的其中一个办法，就是将本人学到的货色将其整顿总结说。博客或者文章 另外一个办法就是我始终置信实际出真知，实际是测验真谛的唯一标准，特地是做工科做技术的敌人们。 一个知识点，一个技术点，或者你乍一看感觉很简略，感觉对你来说是小意思， 可当本人去实际，去实际操作的时候，你会发现。谬误摆出各种各样的问题，你都可能碰到。 用成语来说就是眼高手低。做技术的人大多是沉稳的，都会违心去落地。实现本人的想法。置信看到这里的敌人，你也是这样的人。 与身边人探讨技术这里再和大家分享最初一个办法，那就是多与身边的人沟通探讨技术点。 你会发现。他人晓得的货色本人不晓得当然。方面本人晓得的可对方不晓得。 在和他人探讨的过程中，你可能。清晰的表白本人的思维，表白具体的技术原理，可能让他人听明确这是一种很要害的能力。 并且与他人探讨和沟通，自身就是一种很享受的过程。在探讨过程中，会存在很多的思维碰撞，可能一直的拓宽本人的认知，突破本人的思维形式，甚至很多时候可能开辟本人的眼界。 交一个忘年交其实在咱们的生命中，应该至多有一次忘年交，也就是说有机会能够找一个比本人大10岁左右的人，作为本人的知己。 这样的敌人在本人做要害抉择的时候，可能给予相应的人生教训，可能尽可能的让本人少踩坑。让本人在接下来的方向上能够找到正确，可能让本人的大量工夫放在正确的事件上。 我也冀望，各位可能把本人的工夫放在正确的事件上，而不是大量的耗在如何正确地做事上。 总结来总结一下我写作的起因次要是，可能深刻的学习技术原理，让本人的技术成体系，有一个成型的技术栈。 波及到的学习办法有如下三点 1 整顿本人的知识库，本人的常识肯定要文档化，结构化。便于查找，能力高效应用。 2 总结技术文章，公布技术博客，让本人对技术点技术原理理解的更加透彻，同时还可能帮忙身边的敌人。 3 多与身边的人沟通交流技术，拓宽本人的认知边界，敢于突破本人的固有思维。 最初一个分享就是有机会还是交一个忘年交。对于将来倒退的路，十分有必要有一个这样的引路人。 好了，本期咱们就说到这里，要是文章对你还有点帮忙的话。帮忙点赞评论要是可能分享到你的敌人圈里，那将是对我最大的激励和反对。 技术是凋谢的，咱们的心态也应如此。将来的路线上拥抱变动，怯懦前行。大家一起加油！ 作者：小魔童哪吒

苦海无边，回头无岸。01晃晃悠悠的，在互联网行业工作了五年，默然回首，你看哪里像灯火阑珊处？ 初入职场，大部分程序员会感觉苦学技术，当前会逆风逆水升职加薪，这样的想法没有错，然而不算全面，五年后你会不会持续做技术写代码这是外围问题。 初入职场，会感觉致力加班能够一直晋升能力，能够学到技术的公司就算薪水低点也能够承受，然而五年之后会认为加班都是在一直挤压本人的回升空间，薪水低是人生的天花板。 这里想说的关键问题就是：初入职场的认知和想法大部分不会再实用于五年后的认知。 工作五年之后面临的最大压力就是抉择：职场天花板，技术能力天花板，薪水天花板，三十岁天花板。 如何面对这些问题，是大部分程序员都在思考和纠结的。做抉择的惟一参考点就是：利益最大化，这里能够了解为职场更好的升职加薪，逆风逆水。 五年，变动最大不是工作教训，能力积攒，而是心态，分明的晓得事实和现实之间是存在微小的差距。 02回首本人的职场五年，最认可的一句话就是：学会适应变动，并积攒能力。 变动的就是，五年的工夫技术框架更新迭代，开发工具的变迁，公司环境队友的更换，甚至是不同城市的漂泊，想着能把精神和灵魂安放在一处，有句很经典的话就是：惟一不变的就是变动自身。 要积攒的是：解决问题的能力，思考形式，拓宽认知。 这种很难直白的形容，属于集体认知的领域，不同的人有不一样的认识，所以只能站在大众化的角度去思考。 首先聊聊技术，大部分小白级别的，都心愿本人的技术能力一直进步，争取做到架构师级别，然而站在以后的互联网环境中，这种想法实现难度还是偏高，这里既不是打击也不是为了抬杠。 能够察看一下现状，技术团队大的20-30人，小的10-15人，能有一个架构师去专门治理底层框架都是少有景象。 这个问题的起因很多，首先架构师的老本过高，环境架构也不是须要常常降级，说的好听点可能框架比我的项目生命周期更高。 所以大部分公司的大部分业务，基于现有大部分成熟的开源框架都能够解决，这也就导致架构师这个角色通常由我的项目主管代替或者级别较高的开发间接负责，这就是现实情况。 这就导致技术框架的抉择思路就是：只选对的。即这方面的人才多，开源解决方案多，以此升高技术方面对公司业务倒退的影响。 那为什么还要一直学习和积攒技术能力？如果没有这个能力，程序员岗位可能基本走不了五年之久，须要用技术深度积攒一直解决工作中的各种问题，用技术的广度晋升本人实现业务需要的认知边界，这是安放精神的基本保障。 这就是导致很多五年当前的程序员压力陡然升高的起因，走向治理岗的另一个壁垒就是业务思维和认知。 03程序员该不该用心钻研业务，这个问题真的没有纠结的必要，只有不是纯技术型的公司，都须要面对业务。 不论技术、经营、产品、管理层，都是在面向业务工作。 从本人职场轨迹来看，五年变动最大就是解决业务问题的能力，职场之初面对很多业务场景都不晓得如何下手，到几年之后设计业务的解决方案。 这是大部分程序员退职场前五年跳槽就能涨薪的根本原因，面对业务场景，基于积攒的教训和现有的开源工具，能疾速给出正当的解决思路和实现过程。 工作五年可能对技术底层的清晰水平都没有初入职场的小白分明，然而写的程序却能够避开很多坑坑洼洼，对于业务的扫视也是很细节全面。 解决业务能力的积攒，对于技术视线的宽度需要更甚，比方职场初期对于海量数据的解决大刀阔斧，然而在工作几年之后见识数据行业的技术栈，真的就是技术选型的视线问题。 什么是掂量技术能力的规范？站在一个共识的角度上看：零碎的架构与代码设计能适应业务的一直变动和各种需要。 绝对比与技术，业务的变动更加疾速频繁，高级工程师或者架构师之所以薪资高，这些角色一方面能适应业务的迭代，并且在工作中具备肯定前瞻性，会思考业务变动的状况下代码复用逻辑，这样的能力是须要肯定的技术视线和业务思维的积淀。 所以职场中：业务能说的东倒西歪，代码能写的明明白白，失去机会的可能性更大。 04从感性的角度看技术和业务两个方面，能让大部分人职场走的安稳顺利，然而不同的阶段对两者的均衡和抉择是不一样的。 在思考如何抉择的时候，能够参考二八准则的逻辑，即在任何一组货色中，最重要的只占其中一小部分，约20%，其余80%只管是少数，却是主要的，因而又称二八定律。 集体真的十分喜爱这个准则，大部分人都不是蠢才，所以很难见异思迁同时做好几件事件，在同一时间段内应该集中精力做好一件事件。 然而单纯的二八准则模式可能不适应大部分职场初期的人，因为初期要学习很多内容，如何退职场生存：业余能力，职场关系，为人处世，产品设计等等。 当然这些货色不是都要用心刻意学习，然而合理安排二二六准则或其余组合是更理智的，首先是业余能力要重点练习，其次能够依据本人的趣味正当抉择一到两个方面去缓缓理解，例如产品，经营，运维，数据等，毕竟三五年当前会不会持续写代码很难说，多给本人留个机会总是有恃无恐。 退职场初期，根本都是从技术角度去思考问题，如何疾速晋升本人的编码能力，在公司能稳固是首要指标，因而大部分工夫都是在做根底编码和学习标准，这时可能90%的心理都是放在根底编码上，另外10%会学习环境架构。 最多一到两年，就会开始独立负责模块需要开发，须要本人设计整个代码思路，这里业务就会进入视线，要懂得业务上下游关联关系，学会思考如何设计代码构造，能力在需要变动的状况下代码改变较少，这个时候可能就会放20%的心理在业务方面，30%学习架构形式。 三到五年这个时间段，是解决问题能力晋升最快的时候，因为这个阶段的程序员根本都是在开发外围业务链路，例如交易、领取、结算、智能商业等模块，须要对业务整体有较清晰的把握能力，不然就是给本人挖坑，这个阶段要对业务流付出大量心血思考。 越是外围的业务线，越是容易暴发各种问题，如果在日常工作中不花心思解决各种细节问题，中午异样主动的音讯和邮件总是容易让人憔悴。 所以努力学习技术是晋升本人，造就本人的业务认知也同样重要，集体认为这二者的重量平分秋色，只是须要在适合的阶段做出正当的权重划分。 05基于技术能力和业务思维，学会退职场做抉择和生存，这些是职场前五年一路走来的最大领会。 不论是技术还是业务，这两个概念仍旧是个很大的命题，不容易把握，所以学会理清这两个方面能力中的公共模块是要害。 不论技术还是业务，都不可能从一家公司齐全复制到另一家公司，然而能够把一家公司的技术框架，业务解决方案学会，并且带到另一家公司，例如技术畛域内的架构、设计、流程、数据管理，业务畛域内的思考形式、产品逻辑、剖析等，这些是外围能力并且是大部分公司人才招聘的要求，所以这些才是工作中须要重点积攒的。 人的精力是无限的，而且面对三十这个天花板，各种事件也会接连而至，退职场中学会合理安排工夫并一直晋升外围能力，这样能力保障本人的竞争力。 职场就像苦海无边，回首望去可能也没有岸边停泊，然而要具备换船的能力或者有个小木筏也就大差不差了。 浏览标签 【Java根底】【设计模式】【构造与算法】【Linux零碎】【数据库】 【分布式架构】【微服务】【大数据组件】【SpringBoot进阶】【Spring&Boot根底】 【数据分析】【技术导图】【 职场】

本文为受权转载内容，转载自公众号「HaloTech 瑶光栈」，作者 HaloTech。 很多人会局限将来的眼光，却遗记了回望过来的教训。间隔辛丑牛年《春节联欢晚会》倒计时 15 天，央视发表：短视频 App 抖音成为春晚独家互动合作伙伴，将于除夕夜为全国人民发放 12 亿红包。 此次流动引发了累计 703 亿次红包互动，再度将抖音及其背地的公司——字节跳动，推上了话题热榜。 咱们看见的是字节向全国人民递出的称心答卷，但其背地的故事更值得深挖。有人称其是一场里程碑式的技术验证，有人形容为一场穿梭风暴的修行…… 明天，就让咱们一起，拉开春晚舞台上这场“战斗”的幕布，看一看这背地的故事。 尾声：挑战降临 “如果 2019 年让咱们做主场，以过后的技术能力没有十足把握。但往年，咱们没有任何犹豫接下了挑战。”2021 年 1 月 13 日，周三。字节判若两人的流动日。客户端负责人肖宇已解决完一天的工作，筹备和共事们去吃一顿大餐。 “团建勾销”，一条告诉赫然呈现在屏幕上，“所有人一起开个紧急会议！” 大家停下步调，面面相觑，隐隐嗅到了战场上的硝烟滋味。 22 点，会议终于开始。原来是白天跟央视接触的市场部共事来切磋抖音要不要承包 2021 年春晚红包我的项目，询问技术侧共事是否反对，如能反对第二天即敲定合同细节。 肖宇关上飞书日历，划到 2 月列表。11 号是元旦，距今有余 1 月。 其实，对字节来说，春晚红包我的项目并不生疏。2019 年，百度以第一身份，抖音以第二身份独特参加了春晚红包我的项目。 “如果那时咱们做主场，以过后的技术能力没有十足的把握”。但这两年，随着字节人才梯队和基础设施的迅猛发展，“所以得悉 2021 年要以第一身份做春晚红包流动时，大家都是蠢蠢欲动的样子”，肖宇回忆起那天散会的场景。 没有犹豫，技术部门拍板了。 1 月 15 日，单干敲定。虽没有对外正式颁布，但我的项目的齿轮已急速转动起来。 infoQ如此说，“春晚流动是百度、阿里、腾讯三家轮流坐庄的技术盛事，毕竟只有具备足够的用户体量，才可能有足够的技术能力撑持起春晚级别的高并发流量。”去年快手和往年字节的呈现，无疑给这个流转于三个互联网大厂之间的年度“保留节目”注入了一股新鲜血液。 然而，相比于今年“前辈们”均匀 50 天的筹备工夫，字节往年只有 27 天，这样极短的筹备周期此前从未产生。倒计时开始，如何能力实现如此艰巨的工作？ 第一幕：发令枪响，启程！"感觉像是始终在筹备高考，忽然文化课改成踢足球，踢的还是世界杯。"中国互联网圈有一句戏言：没有中国人搞不垮的网站。春晚红包流动即是一部记录互联网公司宕机事变的编年史，再强的高并发能力在十几亿观众背后都显得分外软弱。已经参加过春晚我的项目的团队笑称，流动难度级别是“从爬泰山到登珠峰”。 2021 年预留的工夫只有 27 天，应答上更显局促。 其实从 2020 年 10 月开始，抖音始终在筹备春节流动，毫无预兆地将流动主场搬上春晚，"感觉像是始终在筹备高考，忽然文化课改成踢足球，踢得还是世界杯"，肖宇笑着感叹道，“尽管毫不犹豫地接下了春晚工作，头三天却仍是感到心慌”。 我的项目初期，须要思考的方向繁多，每一个环节都不可小觑。就像一艘海上巨轮，只有呈现任何一道细小裂纹，都可能造成万吨淡水涌入的致命结果。因而，在流动筹备阶段，工作脉络梳理和明确外围里程碑节点有着提纲挈领的作用。 春晚流动项目组首先对外围链路、流动链路和惯例链路进行梳理，全面笼罩了我的项目波及的各个方向，并依照优先级由主到次梳理开展。依据春晚工夫倒推，团队确定了 9 个重要里程碑节点，其中包含：3 次压力测试、1 次容灾演练、4 次剧本演练和 1 次实操。 ...

转自@twt社区，作者：Zabbix大叔_乐维。 前言 在过来的几年里，开源产品和商业监控应用程序产生了爆炸式增长，涌现出了一批优良且利用宽泛的监控工具，如Zabbix、Prometheus等，零碎运维人员须要把握这些新工具，以及解决这些工具在日常利用中的各种故障、难题等。咱们将继续在社区和公众号中公布同行分享的相干实用常识和技巧。 一、如何在 Zabbix 执行近程主机的脚本或指令？场景需要： 1、咱们能够通过zabbix_server的web界面的脚本性能实现对曾经装置了zabbix_agent主机实现近程关机而不必手动登陆而后输出关机指令 2、咱们能够通过zabbix_server的web界面的脚本性能实现某个服务的启动敞开和重启 试验配置过程： 1、创立脚本 关上zabbix_server的web配置界面，抉择治理,接着抉择蓝色导航条中的脚本选项,最初点击创立脚本。 脚本名称：自定义 类型：如果是window或者linux主机类型都是抉择脚本。IPMI类型(暂且不探讨) 执行在：有三种类型, （1）zabbix客户端,阐明创立的脚本会在装置了zabbix客户端的主机上运行。 （2） zabbix_server(代理),阐明脚本会在zabbix代理上执行。 （3）zabbix服务器，阐明脚本会在服务器下面执行。 命令：能够填系统命令,或者某个脚本的绝对路径 要求的主机权限:抉择默认就好了 创立一个显示主机ip的脚本 重要：脚本创立实现后,必须到zabbix_agent的配置文件中开启容许zabbix客户端执行近程命令 把默认的EnableRemoteCommands=0改成EnableRemoteCommands=1 重启zabbix客户端,使配置失效 脚本创立实现后，咱们去到zabbix_server的web界面中的监测,而后找到蓝色导航条中的最新数据,找一台曾经曾经装置了zabbix客户端的window主机执行。因为ifconfig是Linux主机的系统命令，所以测试只能找装置了zabbix客户端的Linux主机测试。 而后在主机列中，鼠标左键一下主机名,就会呈现一些咱们自定义和内置的脚本。显示IP的脚本就是咱们方才创立的。 执行后果： 失常的显示出装置了zabbix客户端的linux主机的ip 原文地址：http://www.talkwithtrend.com/Article/247577 二、用 Zabbix 监控网站的访问量需要：监控网站pv和uv的总量和5分钟内的pv和uv的增量 1. PV、UV是什么？ UV：独立访客，每个独立上网电脑视为一位访客，一天之内网站的访客数量 PV：访问量，页面浏览量或者点击量，用户每拜访一次记录一次 2. 依据的拜访日志统计网站PV 和UV总量 [root@server-web scripts]# cd /usr/local/zabbix/scripts/ [root@server-web scripts]# cat pvuv_number.sh /bin/bash desc: used nginx pv and uv uv_number(){ cat /usr/local/nginx/logs/access.log |awk '{print $1}'|sort|uniq|wc -l } pv_number(){ ...

产品经理领有宽泛的常识，可能接触到公司的不同部门和利益相关者。这使得他们处于一个现实的地位，能够围绕预防和应答技术债权发明一种工作文化。咱们提供了一些有用的策略。依据Gartner的2019年产品经理考察，只有55%的产品公布如期进行。这对于按时公布产品的产品经理来说意义重大，因为他们更有可能在公布一年内达到外部指标。在45%的提早公布的产品中，均匀有20%无奈达到外部指标。未能在打算的工夫范畴内公布产品可归因于许多因素，包含不足正规的公布流程、产品开发的提早（谬误、故障、性能蔓延）、未能满足客户的要求、产品质量，甚至供给问题。另一个起因是技术债权。技术债权不仅让开发人员感到丧气，还会导致一系列相干问题：未修补的谬误意味着客户不称心。客户留下负面的产品评论，给营销团队带来挑战。不稳固的架构提早了新个性的公布。销售周期受到影响。高级管理层和投资者对此会提出质疑。 产品经理在促成产品胜利方面扮演着要害角色：愿景、个性、策略、产品公布、市场定位、竞争对手以及路线图。产品经理位于工程、销售、反对和营销相互穿插的十字路口，这意味着他们处于解决技术债权问题的独特地位。这里有一些会起到帮忙的可行策略。 建设同盟关系产品经理的职责应该包含与技术主管、首席技术官和其余部门主管建设牢固的关系。Gartner的考察发现，78%的产品经理将改善外部合作视为他们的三大工作之一，他们的产品失败率较低。花点工夫定期与技术负责人交谈，独特理解公司外部技术债权的水平，并承诺予以解决。开发团队（不肯定是管理层）中是否有任何拥护者违心解决技术债权？防止让人们感觉技术债权是罪魁祸首。相同，把注意力集中在解决债权对你的产品、公司和客户的积极意义上。激励管理层为缩小技术债权提供激励措施，例如劳动一天或外出娱乐活动。 让技术债权公开通明技术债权无处不在，应该成为每一次产品会议的一部分。让它成为一个可操作的我的项目，并寻求定期更新。为了防止看起来仅仅像一个把关者，要致力让开发人员参加解决问题，并为解决技术债权这项工作设定优先级。要分明以下问题：开发人员更喜爱在冲刺中还是专门的工夫来解决技术债权？哪个人负责哪块工作？每个人目前工作量是多少？是否须要更多员工？ 进行必要的发问产品经理的工作是一场在工作和工夫线之间一直转换语境的战斗。产品经理可能是整个组织中对此最为善于的人，他们对一个我的项目的方方面面都有过人的眼光。解决技术债权意味着策略和承诺，但首先须要确定问题的现实性。以代码谬误为例，它会提早产品公布。现实状况是，组织正在跟踪和监控技术债权，并提供一个渐进的口头我的项目列表。如果状况并非如此，提出开放性问题能够让你对问题的重大水平、潜在结果有一个事实而清晰的了解，并就前景开展对话。玩个游戏吧，任何答复“视状况而定”的人都须要往罐子里放一美元。询问内容示例如下： ●是否有策略上的理由推延解决方案（例如期待所应用的特定软件的技术升级）？●是否存在不须要修复的技术债权（如过期的产品供给）？●修复这段代码须要多少工作？●咱们能承诺当前会修复这个代码吗？●谁将负责任何修复，时间表是怎么的？●此时间表是否与其余公布打算、性能更新等相冲突？●不修复此代码对以后客户和将来版本有何影响？●在咱们致力于将来的返工或重构之前须要做些什么？ 将技术债权的补救列入路线图中将技术债权嵌入到路线图时间表中。分配任务和工夫来进行Bug修复、代码审查、保护，以及全面缩小现有债权，以构建更弱小、更具弹性的产品。让路线图尽可能地凋谢和可见，这样开发团队和其余共事就会感觉他们是产品循环的一部分。路线图应该是灵便多变的，但也应该包含一些应答技术债权的硬性截止日期。记住，不是所有的货色都须要重构，你的指标是确定你在这个Sprint、一个月或一个季度所要做的事件的交加，以及你的代码库中有技术债权的局部。要在这些交加点解决技术债权，而不是在交加之外解决。 参考技术债权制订KPI将打消技术债权作为跟踪组织内胜利的形式。围绕具体参考技术债权的产品性能和开发速度创立KPI。如果您的公司应用净推荐值（NPS，可反映口碑）来掂量客户忠诚度，这可能包含无关产品修复提早、破绽等的反馈。有时间接从终端用户那里取得反馈的确会看出问题。 思考如何预防技术债权与技术负责人探讨什么样的策略能够纳入我的项目过程，以缩小技术债权。这可能包含领导、团队培训和结对编程，理解这些是否能够蕴含进产品估算。找出将修复代码的责任全副放在一个人肩上的技能差距。 仔细看待文档一些开发团队致力创立一种机会主义重构的文化，在这种文化中，无论何时何地，只有代码须要清理，就会进行代码修复——不管是谁。尽管这听起来很现实，但在工作量大的顶峰期间不太事实。确保你的公司记录债权和清理债权的责任。这应该是一份常常提及并付诸行动的“活”的文件。在团队成员发生变化的组织中，这一点尤为重要。

新年将至，年味渐浓。大家是不是也和咱们一样，在坚守岗位的同时，心里也开始期待春节的到来了呢？ 老规矩，一年一度的美团技术年货如期而至啦。 在2021年春节到来之际，咱们精选过来一年公众号60多篇技术文章以及10多篇国内顶会论文，整顿制作成一本厚达1300多页的电子书，作为新年礼物赠送给大家。 这本电子书内容笼罩前端、后盾、算法、数据、运维、平安等多个畛域， 心愿对同学们的工作和学习有所帮忙。 大家如果感觉有价值，也欢送转给更多有雷同趣味、踊跃上进的共事、敌人，一起切磋，独特成长。 最初，祝大家阖家欢乐，衰弱安全，和和美美，锦簇花团。新的一年，牛气冲天！ 如何获取？关注「美团技术团队」微信公众号，回复 【2020年货】，即可获取电子书的下载链接，大家可收费在线浏览、下载。 舒适提醒：咱们为大家提供了合集和4个分册的下载链接，大家能够选择性下载或者浏览。 2020美团技术年货合辑：共1308页，约80M；前端篇：共247页，约12M；后盾篇：共391页，约22M；算法篇：共317页，约18M；顶会论文精选：共130页，约17M。因文件较大，可能须要一点急躁。因局部文章中的动静图片无奈在电子书中进行展现，大家能够移步美团技术团队官网博客 tech.meituan.com 或在美团技术团队公众号历史文章中进行查阅，感激了解。 往期技术年货长按并辨认文末的二维码，关注「美团技术团队」微信公众号，回复 【2019年货】、 【2018年货】、【2017年货】，即可获取往期年货下载链接。

具体操作办法： 1: 关上启动台 2: 关上钥匙串拜访 或 Command + 空格间接搜寻钥匙 3:  点击左侧列表中“零碎”选项 4: 找到连贯的WiFi名称，右击，抉择“将明码拷贝到剪贴板” 5: 输出用户本地的用户名 & 明码，回车 6: Command + V 复制明码到所须要的中央 7: 共同进步

往年美国市场谁最景色？当属女股神 Catherine Wood 和她公司 ARK ，她被大家崇拜的最重要一个起因，就是其对翻新技术的精确判断让她率领的基金播种了巨额收益，上面这张图中紫色线为她治理的一只规模最大的 基金ARKK 与纳斯达克 100（彩色线）以及标普 500（彩色）的比照，从 2014 下半年退场至今，ARKK 累计上涨了靠近 500%，碾压基准标普 500，甚至也让作为科技指数之王的纳斯达克 100 黯然失色。ARKK 间断三年都跑赢了基准，并且和其余 ARK 旗下的四个被动基金一起在往年迎来了大暴发。 ARKK vs 纳斯达克 100 vs 标普 500 2014 年底至今各自累计涨幅 最近ARK公布报告《 Big Ideas 2021》，报告具体解读了将来科技领域的几大趋势，话不多说，上面咱们就来具体理解一下吧。 一、深度学习将取代局部开发者当初简直所有软件都由人类来编写，不过很快这个场面将被扭转。将来深度学习将取代人类，通过数据主动编写软件，咱们称那个时代为软件2.0时代，主动驾驶、药物钻研等软件都将由深度学习发明。 当初曾经有了一些例子： 对话机器人：在人工智能的推动下，2020年智能音箱答复了1000亿条语音指令，比2019年减少75%。主动驾驶汽车：Waymo的主动驾驶汽车曾经在旧金山、底特律和凤凰城等25个城市收集了超过2000万英里的理论驾驶里程。消费类利用：应用深度学习进行视频举荐的TikTok，曾经超过了Snapchat和Pinterest的总和。深度学习模型的训练，须要十分大的计算力，尽管硬件和软件的提高使得人工智能训练老本每年降落37%左右，但人工智能模型的规模增长速度更快，每年大概增长10倍。因而，人工智能训练总成本继续攀升，当初最先进的AI训练模型老本1年可能会减少100倍以上。 这个后果掀起了AI芯片的浪潮： 随着人工智能训练老本增长，GPU或TPU的需要也会大幅度减少。ARK预计，将来五年内，数据中心在人工智能处理器上的收入规模将扩充4倍以上，从当初的每年50亿美元减少到2025年的220亿美元。行将到来的深度学习 「部署阶段」，将使人工智能的获取民主化。这个后果不仅让大型互联网公司受害，也会让经济中的每个行业受害。值得一提的是，AI的能力正在从视觉扩大到语言，2020年是对话式人工智能的突破性一年。人工智能零碎终于能够像人类一样精确地了解和生成语言。对话式人工智能须要10倍于计算机视觉的计算资源，将来几年应该会刺激大量投资。 OpenAI的GPT-3就是上文中提到的第一个能 "了解 "语言的AI，当向GPT-3输出对话：「在清理时本公司，A系列股东将收到优先于所有其余利益相关者，就每股A系列股份调配相当于原发行价1倍的金额（『清理优先权』），加上所有应计但未领取的股息。只有本公司在分派该款项后仍有资产。A系列股东将与普通股持有人按所持股份数量的比例参加转换。」 GPT-3能够将其翻译为更加通俗易懂的句子：「如果守业公司清盘，A轮投资人至多会失去他们投资的回报，他们还将与一般股东分享任何残余的资产。」 当然GPT-3还有更多能做的事件，如编写电子邮件、设计网页、用十几种计算机语言编写代码、检索历史事实、翻译语言、诊断疾病和以治疗师的身份进行交换等。 二、ARM构造将更多利用在PC上咱们正在经验一场「算力」反动。更便宜、更快、更省电的处理器正在取代占据了所有处理器支出90%以上的英特尔。对于云计算而言，ARM、RISC-V和图形处理单元(GPU)很可能成为新的强势处理器。在数据中心上以GPU为主导的加速器将成为新的主导处理器。 从90年代的RISC处理器开始的，到英特尔的低成本、源自PC的x86架构，利用PC市场的规模，英特尔颠覆了高端厂商。当初ARM处理器正在利用挪动生态系统的规模来颠覆英特尔，将开源准则利用于硬件，RISC-V也正在成为低成本计算的规范。咱们认为，ARM和RISC-V的组合将从2020年的0%市场份额回升到2030年服务器市场的71%。 回看英特尔，咱们发现它仿佛被解冻在工夫中。已经的世界半导体制作的领导者，英特尔曾经失去了方向，10纳米处理器推延了四年，让其竞争对手TSMC和AMD在2020年引领了市场。甚至2020年曾经过来，英特尔依然没有推出10nm服务器芯片，比台积电正在量产5纳米处理器整整晚了一代。 所以咱们有理由置信，到2030年ARM将成为大多数开发者PC的能源。当初微软也在加倍努力反对ARM处理器上的Windows，苹果公司打算在将来两年内，每三个开发者中就有一个人应用的Mac电脑从x86过渡到基于ARM的中央处理器（CPU），ARK通过数据得出结论：「到2030年，大多数开发者的PC都能够采纳ARM CPU，这将标记着英特尔x86时代的完结。」 同样ARM也可能成为云计算的新规范，2020年推出Graviton 2 ARM CPU，缩小了AWS从英特尔和AMD购买芯片的需要，AWS Graviton 2比英特尔CPU更便宜、更快，每美元的性能高出48%，所以将来AWS可能会将大部分服务器迁徙到基于ARM的处理器上。 三、虚拟世界走近事实虚拟世界由电子游戏、加强事实（AR）和虚拟现实（VR）形成，虚拟世界的简略解释是指任何人都能够随时进入的计算机模仿环境，并能够与虚拟世界中的人物进行互动。 电子游戏货币化模式正在向虚构商品转变，随着电子游戏的倒退，其商业模式也在一直变动。依据ARK的钻研，在过来10年中，游戏内购买占游戏总收入的比例从20%回升到75%。到2025年，这一比例可能达到95%。 ARK认为游戏的货币化水平将进步，因为游戏内购的泛滥，经济实力正在从开发者向游戏玩家转移。事实上，随着进入门槛的升高，很多游戏玩家曾经成为开发者。在咱们看来，这种转变进步了视频游戏的货币化率。在将来5年内，玩电子游戏的每小时老本可能会减少20%。 当初电子游戏曾经成为人们临时「逃离」工作和家庭的自在空间，依据钻研，将来五年内，均匀每人每天玩电子游戏的工夫将从1.1小时减少到1.5小时，这将大大推动 AR 和 VR 的倒退。 当初 AR 已初具规模，在过来的几年里，Snapchat、Facebook和苹果等公司曾经加大了对 AR 的投资，并激励 AR 宽泛应用挪动设施上的工具。到2022年，生产级 AR 头盔应该会减速推动这一趋势。ARK预测，到2030年，AR 市场规模可能会从当初的有余10亿美元扩充到1300亿美元。 ...

作者：Anna Khrupa编译：芒果果 2020 年曾经完结了，在 2021 年的开始，是时候剖析一下过来十二个月里技术世界产生了什么，并思考接下来须要重点关注哪些技术畛域了。 明天，咱们列出了 2021 年的 5 大技术趋势。 趋势一：近程“所有”2020 年寰球疫情的暴发扭转了咱们生存的方方面面，数字化转型和商业重塑之类的事件仿佛成了流行语。人们的工作、娱乐、医疗、聚合等流动根本都在家实现。这种趋势在 2021 年可能不会有太大扭转。 2021 年将连续 2019 新冠疫情带来技术减速发展趋势。 这意味着数字产品和互联网覆盖范围将在 2021 年变得更广。医疗保健、商业、客户服务、企业治理等都会更多地依赖数字化。 在这一趋势下，5G 挪动网络的覆盖范围将持续扩充，5G 服务项目也会越来越多。5G 也将为 IoT 嵌入式零碎提供更要害的连贯职能。 正如 Wi-Fi 联盟预计的那样，Wi-Fi 6E 规范将在 2021 年公布的约 3 亿个新硬件设施型号中呈现。 趋势二：行为互联网行为互联网（IoB）是 Gartner 提出的术语，它是物联网的延长，将技术、行为钻研和数据分析联合在一起。 正如前文提到的，现在很多日常工作和流动都迫转移到数字空间，这导致产生了比以往更多的在线用户数据。对于企业，尤其是电子商务畛域来说，对这些数据的剖析是十分有价值的信息起源，但又不仅仅如此。 公司心愿更好地理解其潜在客户的欲望，促使 IoB 成为了一种独立的策略呈现。 简而言之，IoB 是钻研用户行为，并通过收集信息和反馈来影响用户行为。例如，像智能手表和健身追踪器这样的医疗设施，当初也变得十分风行。它们通过收集用户对于地位、身材流动、心率、体重和身材成分、睡眠工夫、卡路里耗费和倦怠等方面的信息来工作。 佩戴智能手表的人批准智能手表和跟踪器供应商收集并解决所有这些信息。反过来，公司能够利用这些数据进行有针对性的营销，减少销售额，使客户体验更加个性化。除了广告，IoB 技术也实用于医疗保健、汽车（主动驾驶零碎）和企业治理（ERP 零碎开发）。 趋势三：更高层次的道德与平安技术的提高总是引起人们对其带来的道德影响的探讨。像在线医生征询或者应用手机利用治理药物处方这样的事件能够带来很多便当，然而如果你不与软件供应商分享最敏感的信息就无奈取得这些便当。 这就是为什么在 2021 年，企业会分外关注他们数字产品的道德和数据安全方面。网络安全协定将变得越来越简单，以实现加强隐衷的编程，但这也须要更多的估算。机器学习将成为一种在无人参加的状况下晚期辨认攻打，甚至生成进攻模式的信息技术。 至于理论的技术堆栈，咱们能够期待看到与机器学习开发相干的编程语言（Python、 c # 、 c + + 和 JavaScript 等）的遍及。 合乎所有数字道德规范的须要也将给软件开发和测试服务市场带来变动。只管第三方功能测试或全周期质量保证服务等要求对 IT 行业来说不再是新鲜事，但在 2021 年，咱们将看到企业寻求数据隐衷和数字道德保障服务。 ...

对于所有人来说，2020 都注定是不平庸的一年。对网易智企，也是： 2020，咱们进行全新业务幅员降级左手技术，右手商业 成立五周年的网易云信 日活 3亿+；音讯量 10000亿+；SDK 用户笼罩数 8亿+；公布新一代音视频技术架构；笼罩寰球 196 个国家或地区；为 100w+ 企业开发者提供了技术服务；深耕教育、医疗、金融等行业； 以智能为外围的网易云商 联结网易七鱼、网易定位、网易互客能力；打造 GROW 商业增长模型推动企业新商业增长；打造洞察—营销—服务的一体化解决方案； 在 12 月 22 日 SegmentFault 思否公布的中国技术先锋年度评比 | 2020 中国技术品牌影响力企业榜单中， 网易智企荣获【SegmentFault 思否 2020 中国技术品牌影响力-技术品牌营销奖】 网易易盾荣获【SegmentFault 思否 2020 中国技术品牌影响力-技术向善奖】 同时，网易云信、网易易盾入选【 SegmentFault 思否 2020 中国技术品牌影响力企业榜单】 感激 SegmentFault 思否 对网易智企在开发者生态上的认可。 咱们始终保持也会持续踊跃输入优质技术内容，将咱们的产品翻新带给开发者们，冀望发明更多的价值。 年底干货打包，咱们整顿了 2020 年网易智企最全技术干货，将从【技术系列分享】、【技术实际】、【技术专题】、【职场倒退】四个板块开展。 【技术系列分享】 # 音视频 # 技术系列课｜AI驱动的超分辨技术利用现状技术系列课｜从NE264到NE265：视频编码技术缔造美好生活技术系列课｜从0到1 构建实时音视频引擎从0到1  构建实时音视频引擎技术系列课｜网络QoS的均衡之道——音视频弱网反抗策略介绍网络QoS的均衡之道——音视频弱网反抗策略介绍技术系列课｜音视频测试实战——记音视频测试那些事音视频测试实战——记音视频测试那些事技术系列课｜“被动降噪”到底有多厉害？Active Noise Cancelling-被动噪声打消#Node.js 实际# 网易智慧企业Node.js实际（3）| 灰度公布和利用监控网易智慧企业Node.js实际（2）| 平滑公布和前端代码网易智慧企业Node.js实际（1） | Node利用架构设计和React同构# 数字内容风控 # ...

摘要：2020年11月23日，全国832个贫困县已全副清零，一个历史性时刻诞生。在这场了不起的脱贫摘帽致力中，有一群象牙塔里的大学生也参加其中，他们没去垦荒、也没去搞养殖，而是坐在电脑前靠敲代码来扶贫——写的代码越多、修的BUG越狠，扶贫力度就越大！他们就是——“助顺邮我”科技扶贫团队。接下来，让咱们通过本文看看他们都做了哪些了不起的扶贫动作。2019年年底，这群年轻人重点扶贫的贫困县曾经实现脱贫，迈入振兴阶段。把代码放进扶贫里，这群超能想的大学生有一个名字——“助顺邮我”科技扶贫团队。 「 疼痛多年的顽疾，还得靠科技来治疗 」2018年，当一支扶贫队伍第一次踏上长顺县的土地时，他们惊呆了。眼前的贫困地区，基本不是网上传说那般：一个双手毛糙、皮肤黝黑的老农看着田地愁眉不展，要是再找不到销路，农作物就要白白糟践在地里了。 恰恰相反，这个位于贵州省石漠化片区的贫困县，有着地方、省级等各机关事业单位的定点帮扶关系，基本就不愁订单量。还没有到丰登季，贵州省司法厅上司监狱的订单就源源不断的到来，其中不乏国有单位的大订单，这足以解决全县的销路问题，齐全可能让农户的支出大幅晋升。 可这等坏事往往变成了一场空欢喜，农户们非但没有实现创收，甚至还会错过了销售期。 为什么订单如此之多，还会产生这样的事件？这一景象很快就引起了这支扶贫队伍的留神，他们开始到处走访寻找背地的起因，尝试可能找到解决这一问题的突破口。 很快，在深刻理解当地村干部的工作流程时，所有问题的本源便一点点浮出了水面，因为长顺县信息不畅通，导致大量的订单散失。 每次到了丰登节令，各个乡镇的村干部们就开始忙着挨家挨户统计种植品种、丰登产量，通过漫长的统计汇总，再把数据上报下来。整个过程简约耗时，有时如果提交的文档、格局的不同，又会减少很多工作量，而农产品最佳的销售季节也在统计中缓缓流逝。 这就不难理解，为什么长顺县不可能第一工夫满足大量涌来的订单，全县数据孤岛景象重大，每一次信息采集都无比耗时、耗力，只管村干部忙得连口水都顾不上喝，靠人工统计、更新信息的速度仍旧应答不了订单的需要。 在明确长顺县的痛点后，这支来自北京邮电大学由业余传授、研究生、本科生组成的团队，设立了“助顺邮我”科技扶贫我的项目，心愿可能通过本身在科技领域上的劣势，帮扶长顺县实现脱贫。 帮扶我的项目一确立，团队就开始忙着通过华为云ModelArts平台搭建农产品对接零碎，大量优化的网络模型算法，通过灵便调度按需服务化形式提供模型训练、评估与预测。以及OBS对象存储服务器的稳固、平安、智能高效等劣势，解决了算力以及存储空间的问题，大大晋升了开发速度与我的项目过程。 最终，呈现出了一个残缺的农产品对接零碎——通过智能匹配算法，精准量化到每户种植土地面积、种植农产品品种、产出数量等信息，只有把相应的信息输进零碎中，无需过来繁琐的统计工作，全县每个农作物有多少产量，就能高深莫测。 「 象牙塔里走出了扶贫人 」然而，推广应用的过程却不如设想中的那么简略。 因为与农户生存在齐全不同的环境中，对于团队来说很容易上手的零碎到了农户那里却是困难重重。 在零碎实现了80%的时候，团队灰溜溜地拿去让当地农户试用，后果就碰了一鼻子的灰。 他们的零碎仅能在最新版Windows上应用，而农户过后用的是滞后许久的xp零碎。这让整个团队成员信念备受打击，本来认为技术是妨碍脱贫的第一难题，没想到第一关居然卡在了系统升级上，正如我的项目成员苟志斌所说：“象牙塔里的世界和理论社会还是有十分大的差异的。” 短暂的挫败之后，团队开始反思后期调研的不彻底。也意识到对于开发者而言，他们不能理所应当去描述用户画像，没有理论调研，所有都只是凭空捏造的假象。 正因为如此，团队又一次来到了长顺县。在这次考查当地农户在应用电脑、互联网等方面的理论状况中，他们发现不仅只是电脑系统的问题，当地农户还存在应用电脑不纯熟的景象，信息时代的沟通形式、应用习惯对农户来说都是挑战。 有了这次的经验教训，一回到北京团队就对第一版本开始大刀阔斧地批改，从最后的80%退回到40%，前前后后打磨了五六个版本，最初才确定一个残缺的农产品产销对接零碎。 为了能让网络不好的山区都应用到这一零碎，团队岂但须要把前端访问速度至多进步50%，还要实现高效的数据库拜访存储。对于这一问题的解决，团队与华为深度交融，采纳大量的云技术来保障平台整体的性能，通过多个华为的ECS服务器来实现后端的集群部署，并主动进行危险和资源的监控，实时把握后端状况。 华为云的CDN内容散发网络，能将前端内容散发到贵州长顺左近的CDN节点，极大加强了前端访问速度，对网络品质较弱的山区拜访零碎提供了松软保障；而对于最重要的数据库局部也齐全托管到了华为云数据库上，实现了高效的数据库拜访存储，为高并发拜访提供了坚实基础，为数据的安全性也整体晋升了一个台阶。 这个对接零碎不再受电脑版本、零碎新旧的限度，只有有台电脑就能流畅应用。除此之外，团队还在这个零碎中嵌入了自主设计的智能匹配算法，实现了主动匹配订单、畅销预警性能，大大解决了订单散失问题。 为了让所有农户都能看得懂并独立应用该零碎，团队还出了一本非常详尽的说明书，只有依照使用手册一步步的疏导，哪怕不会应用电脑的人也能学会如何应用零碎。 产销对接零碎的应用落地背地蕴藏着这群年轻人敢于推倒重来的劲头，也是他们用本人的所学帮忙长顺县摆脱困境，迈向农村振兴。 从2018年到2020年，长顺农产品产销对接零碎就已接入全县7个乡镇130余位信息管理员，更好承接了年均3000万农产品订单，并且以不低于大宗农产品市场交易价格发售，让农户的支出有了大幅晋升。 「 巧用华为语音交互服务，机器人也能听懂方言 」农产品产销对接零碎的顺利完成，让团队成员看到技术不仅解决了农户长年来的问题，还播种了农户们的称誉与认可，这些都让这群老成持重的年轻人充斥斗志。 其实，在刚退出助顺邮我我的项目团队时，不少人都是将它视作一次社会实际流动，只是想测验本人所学的技术是否能利用在实操中去，没想到比起产品，他们最大的播种反而是做公益时实现本身价值的满足感。 所以，都还没有好好劳动一下，他们又开始坐在电脑前敲起了代码，这一次是要研发游览导览零碎。 贵州作为全国出名的游览圣地，贵州省长顺县就有一个3A级旅游景点，名叫神泉谷，景区很大也很美，每年都有不少人前来观光玩耍。可是，因为服务人员数量少、谈话的口音重，经常无奈及时处理问题，导致游客的玩耍体验大打折扣。 既然没人做向导，那就让机器人来上阵！不光要为游客优选举荐游览线路和计划，还要肩负起带货的重任，做好当地农产品采购，真正实现用科技进步景区导览服务体验。 现实总是美妙的，但要实现起来并不易，与农产品对接零碎相比，这一项目标难度有了大幅度的晋升，尤其是智慧导览机器人的语音交互，波及到了机器学习、深度学习等相干算法，对算力和存储空间要求很大，依附现阶段团队的情况切实很难解决。 好在这一难题并没有让他们困扰多久，通过到处打听、多方比照，他们终于找到了解决之道。 加入互联网+大赛期间，团队导师与华为结下了渊源，期间正好也是机器人我的项目开发进行中，华为向这只团队提供了帮忙，用华为的昇腾及其机器人相干框架实现增强算力，实现离线 VUI 交互；借助华为的语音交互服务为智慧导览机器人我的项目的语音交互局部高度赋能。 在理论利用中，他们发现华为语音交互服务解决了很多让他们感到辣手的问题，其中最大的感触，就是华为语音交互服务的高识别率，很好地解决了当地人说方言的问题。因为地处偏僻，普通话在当地普及率不高，很多人谈话都有比拟重的口音，只有高识别性的机器人能力做到用方言交换。 其次，华为语音交互服务具备反对多种实时语音转写模式、实用于各类简单场景等劣势，也让团队的构想成真——让游客可能通过询问机器人，就能够获知对于路线、餐饮、住宿等等信息；机器人还能将语音辨认成文字，让游客通过给出的提醒词，失去更多的服务与信息。 现在，智慧游览导览机器人领有优惠揭示、精品推送、产品信息查问、地图显示等性能，在过来稳固投入运行的两个月里，累计接待了游客80万人次，在很大水平上缓解了景区的经营承载压力，让当地旅游业有更好的发展前景。 「 实现“智慧小城”，先从“扶贫”、“扶志”开始 」智慧城市不只是大城市的专利，在扶贫之初，政府就曾经把“智慧小城”的搭建布局进去了。搭载当地倒退布局的列车，助顺邮我团队在科技倒退与扶贫农村之间建起了桥梁，将脱贫攻坚产业化数据库等服务广、利用强的当地急需我的项目落地到平台上，通过当地对各个县的要求，倒退合乎本人特色模式的智慧平台。 在团队的致力、指导老师的奔走下，联合当地的倒退布局，长顺县建起了“智慧小城”的架子，有了5G信号，实现贵州省第一个启动5G建设的县市，将来无人机、航拍、停车违章等现代化的技术建设，团队能够更好的参加到其中，助力农村倒退。 5G的建成迈出了“智慧小城”的第一步，华为在往年9月份提出“智能体”概念，以云为根底，以AI为外围，构建一个立体感知、全域协同、精准判断和继续进化的凋谢的智能零碎。5G的倒退正好是实现网络无缝笼罩和万物互联的根底。将来将是一个物理世界和数字世界的交融。 实际中，团队逐步形成以科技扶贫为主引擎，赋能教育扶贫、文化扶贫的“三驾马车”并驾齐驱的扶贫策略，帮忙贵州省长顺县迈入农村振兴当中，实现“扶贫先扶志，扶贫必扶智”的志智双扶。 从2018年开始，团队就陆续返回长顺县四中做教育扶贫工作，两年工夫里有41名团队成员总共累积教学服务长达21000小时。在这21000的小时里，除了一些代课的工作外，他们最长做的事件就是一直致力激发孩子们对迷信的趣味。 在线下，他们会做各种对于科技的展览、流动、较量，不仅仅只是做一些常识的科普，更重要的还是心愿能在孩子心中撒下一颗学习科技的种子。 尽管，一开始这类科技展的功效往往不太如意，比起钻研各类技术，孩子们更像是在一起凑个冷落罢了，陈腐劲一过就不关怀了。但驻守在学校里的老师，还是判若两人地在保持，甚至团队还研发了传邮课堂AIMOOC平台，基于产销对接零碎和可视化数据库与华为深度交融的成功实践，AIMOOC也将仿照这个模式，通过应用华为云提供的ECS、CDN、SQL来保障服务的高可用和高并发，并在华为云OVD服务是上进行大量视频等媒体内容的高效治理和疾速的内容散发，通过AIMOOC平台让学生都能学习优质人工智能根底课程。 用科技扶贫，不仅要搬走挡在致富路上的大石头，更要能造就出本人的人才，在不久的将来率领他乡依附科技凋敝倒退。团队的致力，也正在耳濡目染中影响当地的学生，一个初三孩子看了录制在VR眼镜里神泉谷的风景后，兴奋地说：“像是把整个神泉山都装进了VR眼镜里，太神奇了，当前我也要去学。” 现在，他们打造的AIMOOC平台曾经在济南、银川等50余所中小学进校应用；产销对接平台也已与河北威县等地签订落地协定；智慧游览零碎也与湖北峡州旗下6家景区达成单干协定…… 置信在高技术人才的推动下，将来的城市将“能感知”“会思考”“可进化”“有温度”。 「 用代码撬动将来，年轻人不可或缺 」随着2019年年底，长顺县正式摘掉“贫困县”的帽子，它也开始缓缓淡出了助顺邮我团队的世界，两年的经验，让团队日渐成熟，也越发动摇脚下正在走的路。 在整个过程中，华为也在用本人的所长反对着这群年轻人，让他们可能将所想变成事实。 在往年所反对的第六届中国国内“互联网+”大学生翻新守业大赛，华为不仅邀请专家对较量进行领导，还为参赛者提供鲲鹏、昇腾、华为云资源反对。 助顺邮我团队作为参赛方，也是全方位出现了在长顺县所获得的扶贫成绩。让大家都看到了，这群暮气沉沉的大学生们，正在挑起了本人的担子，用所学让扭转产生，用所学让畅想成真。 大学生是推动社会飞速发展的主力，为造就更多数字时代的优秀人才，华为联手教育部，在无关高校建设“智能基座”产教交融协同育人基地，现已在北京大学、清华大学、上海复旦大学、上海交通大学、西安交通大学、哈尔滨工业大学等72所高校，把鲲鹏、昇腾系列课程融入计算机专业、软件工程业余、人工智能业余、电子信息业余进行首批试点。 为此，华为还联结出版社、各高校学科带头人，面向高校师生及开发者陆续推出鲲鹏、昇腾系列学习教材和教辅材料。将来，“智能基座”我的项目将全面推广，笼罩更多高校，真正实现产、学、研的全面协同。 置信在不久的将来，会有少量高端人才从“智能基座”产教交融协同育人基地中涌入社会，他们终究会用所学造成一股弱小的力量，推着整个产业一直大步向前走。 ...

摘要：谁说程序员就只能写代码呢！华为扫地僧的才艺是齐全能够solo出道的那种。忍不住想要和你们分享下我9月份的高兴呀！Mark下最近实现的一件超了不起的事件！我去你们口中他人家的公司—华为啦！这次采访了十位技术大佬，他们也是传说中的华为扫地僧！ 我超级开心这次被邀请去采访华为的技术大牛们！缓和又冲动！ 诚实讲，三天的拍摄几乎忙到飞起，每天的感觉就是累、很累、十分累，保持拍完的我都忍不住要为本人打Call！尽管累，然而超级开心呀！因为作为一个程序媛，碰上了真正的程序员大神，能从前沿技术、职业倒退等各个方面学习到十分多。成就感满满！ 之前，很多人在我的视频下回复“还是好好写你的代码吧”，采访完华为的大牛后我只想再次强烈地示意，程序员也是爱折腾本人喜爱的事件，千万不要给本人的生存设框。这些华为扫地僧，有的是摇滚老炮，有的是陶笛小王子，才艺是齐全能够solo出道的那种。谁说程序员就只能写代码呢！ Get ready with me，接着往下看叭~这次，咱们来到的是华为深圳坂田基地。进去的第一感觉就是满眼绿。沿路两旁绿植覆盖面积很大。最次要的是，华为坂田基地的地标研发核心大楼，也是绿色的。华为自身就很强调绿色经营、绿色世界的理念。你们也来感触下。 华为坂田基地中地区的命名，都是科学家的姓名，这是一种对科技大神的某种致意。也心愿这种迷信精力能代代相传。 作为一个爱学习的程序媛，华为的最美图书馆——坂田B1-4楼图书馆也是我要打卡的中央哦。环境真的没得说，很大又超级丑陋的那种。 他们最近还有收费喝咖啡的流动，据说小熊游泳和西柚咖啡供不应求。害！艳羡他人家的福利么？ 以上只是华为坂田基地的冰山一角哦。整个基地真的十分大，心愿下次有机会再好好逛。 （正片刚刚开始！！！）马全一老师是我此行采访的第一位扫地僧。他是一个开源经营专家，很善于容器技术、DevOps等。见到他时我还是有些缓和的。但他自己很nice，十分real，始终在被动和我谈话，缓解了我的小缓和。 马老师和我有一样的困扰，那就是——减肥。马老师说要在9月的HC大会之前减下来，以建立本人“管制体重的男人”人设。工作略重，马老师加油，我也加油减肥！ 王启军老师是华为云IoT首席架构师，他就很有程序员的那种内敛和腼腆的气质，谈话语气温温柔柔的，让人特地难受。王老师喜爱美食，据说，他的爱人喜爱上他很大水平也是因为他做饭好吃。所以，大家get找到女朋友的办法了么？ 黄之鹏老师是MindSpore开源社区经营负责人。和他聊完之后，我只想说，超！极！有！梗！不愧是经营大佬。因为是天津人的关系，黄老师谈话自带bgm。他在社区负责人之外，还领有百万粉丝油管账号。想为大佬打call。 黄老师说，他的共事常常吐槽他两句话，一个是“你感觉这是正常人的工作强度吗”，另一个就是“人就不能犯一次错么”。是不是很有画面感？像极了你和老板聊天时的心田os。 姚冬老师是华为云利用平台首席技术布道师，比起写代码的能力，姚东老师更重视程序员的软实力。姚老师长年健身，还是一位马拉松达人。相当有毅力。 有意思的是，我在采访中还遇到B站爱好者。何剑老师尽管是华为智能计算专家，但却长期潜水B站进行学习。请把何剑大神的名号打在公屏上。 张昆和我一样是90后哦！但他曾经是华为云数据库首席产品专家，真是年少有为。张昆老师就是非典型技术男啊。他喜爱高尔夫、冲浪、骑机车，喜好相当丰盛呀！你看，华为的大神也在像你们说我的那样“不务正业”呀。 王泽锋老师是华为云云原生开源负责人，也是一个喜好丰盛的大神。萨克斯、陶笛这些乐器都不在话下，爬山养鱼也玩得很溜。我对王老师印象最深的一点是，他齐全是B站资深粉丝。十几年前他就通过答题成为B站注册用户。刚玩几年B站的我自愧不如呀！ 相比前几位，孙雄伟老师在技术上钻研地更深一些，理解华为的人应该听过鲲鹏吧，孙老师就是华为计算根底软件首席架构师。要晓得，做根底软件就是为产业打好底座，十分有技术含量。 他说，“因为咱们做的这些事件应该来说挑战都是挺大的，所以必须要保持，始终坚持下去，而后每一步都有提高，这样子始终到起点。”给孙老师一个大大的瑞思拜。对于这群分心搞研发的老师，我打心里示意尊敬。 田文罡老师是真正意义上的华为扫地僧。因为他从毕业到当初曾经在华为工作了16年。整个职业生涯都和华为绑定在一起。每当他聊起做的数据库，眼里真的有光！可能，这就是酷爱的起因吧。 分享一段田老师的话，“还是要酷爱每一个行业，把这个行业给钻研透钻研深，因为任何一个行业钻研上来，你就发现他的常识是无穷无尽的。另外一方面，一个人在一个畛域钻研的比拟深的话，集体的前途倒退其实是不必去思考太多的。”所以呀，咱们要酷爱本人的事业，并且坚定不移。 陈亮是华为云AI首席技术布道师。他是一个外向型IT男。曾经踢了20年足球，也和公众一样喜爱梅西和C罗。谈起前几天欧冠那场拜仁和巴萨的对决，陈亮也有很多感叹。 “梅西从此就想要退出绿茵场了，甚至当初闹出来跟巴萨要解约”。喜爱的球星要服役，陈老师也有诸多不舍。 十位老师尽管性情各异，但他们都很有韧劲，专一力极强。毕竟成为华为扫地僧，就是要默默潜修内功。他们身上的这种保持、专一，可能也是华为精力的诠释吧。 之前，很多业内的敌人在问我，程序员到底有没有天花板啊？过了35岁到底该做什么呢？ 我从这些华为扫地僧身上失去的答案是，只有在你从事的畛域，很业余、很用心，始终做本人酷爱的事件，你就没有所谓天花板一说。 我见到的这些技术大牛，他们有的曾经过了35岁， 但他们的心态真的十分年老。还是能够和年轻人一起玩桌游、玩狼人杀，而且在工作上超级致力，超级虚心。在他们身上齐全看不到天花板啊。 所以啊，肯定要保持做你喜爱的事件！向大佬学习！ 以上就是我这次华为之行的全副啦。更具体的采访要继续关注我的B站号（Christinaaa呀）哦！华为扫地僧系列视频，你们都要给我看！ 先放点花絮~ 点击关注，第一工夫理解华为云陈腐技术~

简介： 「智能运维大数据平台」是一款开箱即用的运维监控平台，通过特有的平台性能能够将企业的基础架构、应用程序、日志治理联合在一起，提供对立采集、对立存储、关联剖析、对立监控企业业务保障能力，保障企业业务稳固高效运行，同时利用离线计算、实时计算、机器学习等技术，实现运维数据共享、数据开发和加工能力，让开发人员、经营团队和业务团队协同工作，构建和改良软件应用程序，并帮忙企业理解业务和用户应用状况。 导语从马车到汽车是为了晋升运输效率，而随着时代的倒退，现在咱们又心愿用主动驾驶把驾驶员从开车这项体力劳动中解放出来，减少运行效率，同时也可缩小交通事故发生率，这也是企业对于智能运维的诉求。 从人工运维到自动化运维是为了缩小人力老本，升高操作危险，进步运维效率，但自动化运维的实质仍然是人与自动化工具相结合的运维模式，仍有局限性。为了继续高空向大规模、高复杂性的零碎提供高质量的运维服务，智能运维（AIOps）应运而生。 本文，袋鼠云将跟大家分享智能运维大数据平台（一款开箱即用的运维监控平台）在Oracle数据库运维场景下的具体利用。 数据采集应用平台第一步是数据接入。要做好Oracle的运维，须要哪些数据撑持？依据咱们运维Oracle日常的经验总结，以下几类数据是特地重要的： 实例和数据库根底信息 包含实例的版本、Patch、启动工夫、实例参数、主机根本配置信息。数据库健康检查 查看数据库是否能失常连贯，读写响应工夫是否失常。实例根底性能数据 包含业务的QPS、TPS，实例和主机的CPU使用率、内存使用率、连接数使用率，SQL解析状况，数据库的逻辑读、物理读，数据库锁期待情况，以及RAC集群间的通信情况。Oracle期待事件 采集Oracle外部期待事件的类型、期待次数和耗费工夫。从期待事件能够判断实例运行的整体健康状况，定位实例瓶颈。数据库空间应用信息 包含表空间文件占用空间、表空间应用空间、长期表空间应用状况、UNDO表空间应用状况。须要实时监控表空间应用状况，防止表空间占满引起故障。数据库Session信息 Session信息记录了实例以后运行的SQL状况，记录了以后阻塞Session的具体信息，比拟常见的如锁期待。通过Session信息，不便疾速定位实例中的阻塞景象。数据库备份状况 在数据库运维畛域，备份重于泰山。每天都须要查看数据库的备份状况，包含备份是否胜利，备份耗时，备份占用空间等。DataGuard运行状况 DataGuard是Oracle高可用最罕用的计划之一。须要实时检测Oracle DataGuard的运行状况，包含日志传输是否失常，日志利用提早。日志信息 数据库的告警日志、TNS监听日志。从日志中能够发现数据库外部运行谬误、异样的客户端连贯信息等。上述的数据采集，曾经集成在产品中。用户只须要在数据库性能采集模块配置接入信息，就会主动采集这些数据。 数据接入之后，产品上会从几个方面来应用这些数据： 仪表盘 零碎默认带了Oracle场景的通用仪表盘。用户也能够依据本人的应用习惯，通过SPL的形式配置自定义仪表盘。监控告警 零碎内置常见的监控告警。也能够通过SPL的形式配置自定义告警项。数据只有采集到了，就能够用于配置告警。智能巡检 零碎反对配置自定义巡检规定，按用户定义的工夫距离，定期进行数据库巡检。日志剖析 基于零碎采集的Oracle告警日志、TNS监听日志，除了应用根本的日志搜寻、监控告警，也能够配置一些日志剖析的场景。本文重点介绍仪表盘的应用。 Oracle仪表盘仪表盘是数据可视化展示的根本模式，便于用户从直观上理解零碎的整体运行状况。 3.1 Oracle实例总览 Oracle总览Dashboard次要包含这几个局部： 实例统计，包含实例总数，异样实例数，数据库数量，实例版本散布。通过这几个指标，能对接入零碎中的实例有一个大体的理解。 TOP实例，包含忙碌率TOP实例，沉闷会话数TOP实例。 通过这2个指标定位忙碌的实例。 异样实例列表 这个表格展现所有无奈连贯的实例，包含连贯报错信息。TOP性能趋势图 选取数据库的外围指标，对整体实例的运行状况有一个整体的理解。选取的指标： DB Time使用率：体现实例整体忙碌水平DB CPU使用率：CPU资源的使用率。流动会话数：是否后SQL积压会话数使用率：Session资源使用率QPS／TPS：展示业务申请吞吐量 3.2 Oracle实例详情 该仪表盘用于展示单个实例的运行具体情况。仪表盘次要分如下几个局部。 实例信息 显示实例的根本信息，包含主机状况，实例运行状态，实例的版本，数据库的角色，读写模式等实例运行状况 展示实例的外围运行指标。 阻塞会话数／沉闷会话数DB Time使用率实例以后会话数使用率CPU使用率趋势实例会话数趋势SQL执行量／SQL解析量实例逻辑读／物理读实例网络流量实例IO申请次数 3.3 Oracle实例空间总览 该仪表盘展示实例的空间应用状况。次要包含几个局部： 实例总空间散布 展示所有实例的空间散布状况。实例应用空间TOP 展示空间使用率TOP实例的空间变化趋势。实例表空间相干信息 展示所选实例的表空间数量、实例总空间以及空间同比和环比、UNDO空间和TEMP空间、闪回区空间应用状况。 实例表空间使用率和占用空间排名。实例表空间使用率TOP趋势 实例表空间列表 展示实例所有表空间的空间应用状况。 3.4 Oracle阻塞会话 该仪表盘展示实例中阻塞会话的状况，仪表盘次要有几个局部组成。 TOP阻塞会话趋势图 展示零碎中所有实例的阻塞会话数变化趋势。如有阻塞会话，须要特地关注。实例等等事件分布图 展示所选实例的阻塞会话的期待事件散布状况。阻塞源剖析 展示哪些Session引起了其它Session阻塞期待事件趋势 实例期待事件趋势 阻塞会话列表 以表格的模式展示阻塞会话的详细信息，包含： ...

HttpRunner接口自动化测试框架

debugtalk博客

httprunner 源码阅读

Anthony_tester的博客

“从本质上讲，技术没有好坏之分。关键是用它来支持你的目标和价值观。”这是卡尔·纽波特(Cal Newport)的《数字极简主义》一书的封面语。技术是我们所创造的、一个中立的工具，它可以由用户的意图来塑造。然而，对于数字技术的用户——无论是智能手机、社交媒体，还是电子邮件——大多数时间，情况似乎并非如此。事实上，我们中的许多人都缺乏对如何“正确”使用设备的认知。 越来越多的学术界人士也认识到了这一新情况。我们感觉自己处于一种永久分心的状态，发现自己在社交媒体上不知不觉地从电子邮件跳到Slack再到新闻——然而，这一切都是以牺牲我们的主要任务时间为代价的。因此，这是否也同样意味着，技术不是由用户控制，而是由设计者控制的呢？有批评人士警告称，那些创造数字技术的公司正以各种方式让我们沉迷于他们的产品，劫持我们的注意力，改变我们的日常行为和精神状态。这就是为什么我们与科技的互动常常让我们感到失控和低落的原因。 但这并不能解释:技术是否也可能违背设计者的意图？马克•扎克伯格(Mark Zuckerberg)并非有意让Facebook被用作缅甸种族灭绝行动的一部分、iPhone的前置摄像头其实初期也不是为了自拍而设计的。 尽管以上这两种论调截然相反，但它们都有一个共同的假设：技术是由人类的意图和目标所塑造的工具——无论是用户的意图还是设计师的意图。根据技术哲学的奠基人之一马丁·海德格尔的“关于技术的问题”一文，这个假设可能是完全错误的。他认为，塑造技术的不是我们，而是技术塑造了我们。 Heidegger with a bucket. Photo by Digne Meller Marcovicz 当然，把技术理解为一种工具、一种我们用来实现目标的工具，这不可能是完全错误的。例如，一个桶，一个古老而简单的技术，可以通过思考我们用它来做什么理解它。即使是像飞机这样复杂的现代技术，通过思考它的用途也能使它被更清楚地理解。这部分内容海德格尔同意了。但是他又说，这并不是关于技术的全部真相。把一个部分的真理提升到整个真理可能比完全错误更令人盲目。 对于海德格尔来说，这一套以现代技术为工具来追求我们的目标的认知是只是另一个更大的图画的一部分，在这个图画中，不仅仅是技术，而是整个世界，都被视为工具。海德格尔认为，我们将世界看做一个长期的“资源库”，它是一系列用于实现我们目的的资源。 在海德格尔看来，技术之所以能够揭示这一点，是因为揭示是技术的本质。他得出这一结论的方式是提醒我们，一项技术首先是一种人工制品——一种由天然材料制成的东西。而人工制品的作用就是揭示隐藏在世界内部的内在可能性。例如，一棵树有可能成为一张桌子、一张纸或一节车厢上的一个轮子。这些资源的可能性甚至在它们被技术性创造之前就已经隐藏在其中了。 技术也揭示了自然的整体特征。海德格尔认为古老的技术，如风车和桥梁，揭示了自然的力量，就像神一样，是值得尊敬和重视的。在他看来，现代技术揭示了自然是一种长期的储备，是为我们的利益提供无穷无尽的材料的“库”，是一种达到我们目的的手段，是一种可以用来使用的工具。 这一说法的真实之处在于它所产生的后果:环境危机。即使是在我们谈论这场危机的方式中，我们也能看到它的框架。例如它将如何影响我们的生活方式、地球的自然资源以及可持续性。换句话说，就是把自然看作是为我们而存在的东西，我们需要保护它，以便在未来继续利用它并从中受益。 正如诺伦·格茨在《虚无主义与技术》一书中所论述的，海德格尔将技术与自然视为工具的这一观点问题在于，它给我们制造了一种错觉，即一切都是在控制之中的。自然与技术是为我们服务的，但同时我们自己也成了这种工具框架的牺牲品。我们是否也成为了技术的工具？ 让我们会回到“对现代科技已失去控制的恐慌”这一议题上。我们一直随身携带的手机如果用海德格尔的理论来看，那是因为它不是技术服务于我们的目标，而是我们服务于我们技术的目标。我们生成数据和行为，使其更有效地运作，我们的生活方式不是为我们的目标服务，而是为技术的目标服务。 这与技术被设计者以牺牲用户为代价来控制的说法很接近。在Shoshana Zuboff的《监视资本主义时代》一书中，她提出了这样的观点:技术已经成为一种服务于新形式资本主义的工具，进而，人类也被工具化了。对于Zuboff来说，人类的工具化并不是技术本身的一个特征，而是在资本主义社会刺激下，人们被激励使用它们来创造价值。 换句话说，技术是中立的——是资本家们将用户变成了技术的工具。 这种差异可能看起来是学术性的，毕竟Zuboff和Heidegger似乎都在说，我们的技术正在把人类变成工具。但是，为什么会发生这种情况？对于Zuboff和其他人来说，人类的能动性是导致问题的原因。因此，人类群体的延伸——或者更确切地说，是政府对科技公司的限制——是解决方案。但对于海德格尔来说，人的能动性并不在其中。他的观点是，技术本身有着超越人类动机和意图的逻辑。 这一点在机器学习技术中越来越明显，甚至连机器学习技术的创造者也常常对此视而不见。有些人认为，自主的人工智能是人类存在的风险之一，但海德格尔让我们思考的是，所有的技术从来都不是完全在我们的控制范围之内，它所揭示的关于人类的东西不是由我们决定的。社交媒体、网络约会和网络文化带来了新的社会互动形式。以前隐藏在人类世界里的种种可能性现在都浮出了水面。Twitter和Facebook的设计者无意中发现了这些新型的社交行为，比如恶意挑衅或人肉搜索这样的网络暴力行为，但它们不能被忽视，因为它们是网络技术的“衍生品”。 这并不意味着海德格尔是一个技术宿命论者。他确实认为有一种方法可以与让人类与技术建立更好的关系，意识到工具心态是一个好的开始。当我们认识到它只是构建世界的一种方式，而不是事物本身的方式，我们就能被它解放出来，接受其他看待世界的方式。海德格尔认为，艺术尤其可以帮助我们摆脱技术的工具框架。对他来说，艺术揭示了世界上一些科学/技术手段所不能触及的方面。艺术作品有能力向我们揭示世界是有意义和价值的东西，而不仅仅是一堆可以使用的东西。 对于那些认为技术问题可以由更开明的用户或政府来解决的人来说，这一切可能都是苍白无力的安慰。但尽管这是从技术悲观主义的高度出发的论点，但海德格尔的信息是乐观的。他让我们意识到，有很多看待世界和彼此的方式并不依赖于科技的棱镜。这最终是一种解放思想。我们可能无法控制技术，但我们也不需要被它束缚。 原文链接：https://onezero.medium.com/do... 以上信息来源于网络，由“京东云开发者社区”公众号编辑整理，不代表京东云立场。 点击“京东云”了解京东云对象存储产品

今天的知识点 (2019.10.08) —— 第175天[html] HTML5的哪些新特性是令你最兴奋的？[css] 如果css文件过大时，如何异步加载它？[js] 请说说你对promise的理解[软技能] 你对“技术服务于生活”的理解是什么？《论语》，曾子曰：“吾日三省吾身”（我每天多次反省自己）。 前端面试每日3+1题，以面试题来驱动学习，每天进步一点！ 让努力成为一种习惯，让奋斗成为一种享受！相信 坚持 的力量！！！欢迎在 Issues 和朋友们一同讨论学习！ 项目地址：前端面试每日3+1 【推荐】欢迎跟 jsliang 一起折腾前端，系统整理前端知识，目前正在折腾 LeetCode，打算打通算法与数据结构的任督二脉。GitHub 地址 微信公众号欢迎大家前来讨论，如果觉得对你的学习有一定的帮助，欢迎点个Star, 同时欢迎微信扫码关注 前端剑解 公众号，并加入 “前端学习每日3+1” 微信群相互交流（点击公众号的菜单：进群交流）。 学习不打烊，充电加油只为遇到更好的自己，365天无节假日，每天早上5点纯手工发布面试题（死磕自己，愉悦大家）。希望大家在这浮夸的前端圈里，保持冷静，坚持每天花20分钟来学习与思考。在这千变万化，类库层出不穷的前端，建议大家不要等到找工作时，才狂刷题，提倡每日学习！（不忘初心，html、css、javascript才是基石！）欢迎大家到Issues交流，鼓励PR，感谢Star，大家有啥好的建议可以加我微信一起交流讨论！希望大家每日去学习与思考，这才达到来这里的目的！！！（不要为了谁而来，要为自己而来！）交流讨论欢迎大家前来讨论，如果觉得对你的学习有一定的帮助，欢迎点个[Star] https://github.com/haizlin/fe...

那么在云上安全备受瞩目的大环境下，云态势感知技术又如何为安全保驾护航呢？在未来又有着怎样的发展趋势呢？为此，京东云产品研发部产品经理梁洋洋，专门为大家解读了云态势感知的进化论。 01态势感知出现的技术背景虽然态势感知是近几年新有的安全名词，但对于有安全背景的人来说，态势感知并不陌生，它是跟SOC（安全操作中心）对标的产品。 在2010年之前，安全威胁不是特别多，主要还是集中在网络层面，所以当时的SOC产品还是停留在NOC（网络操作中心）基础架构的阶段。 当时比较出名的产品是Cisco-MARS产品，主要是把所有Cisco的交换机、路由器、防火墙、IDS、IPS数据都收集上来，然后放到MARS里面来关联分析，形成攻击拓扑图。这就是态势感知最初始化的雏形，也就是把网络层面的安全数据收集到NOC的产品当中。在安全技术还未成熟的2010年，这个技术足以让人眼前一亮。 由于安全威胁场景不断变化，普通的NOC产品无法分析出APT攻击，加上安全设备和安全事件的突增，传统的NOC已无法满足需求，所以在2010年-2015年逐步兴起SIEM/SOC平台。SIEM是安全信息和日志管理平台。可以把主机上的安全日志包括登录日志都搜集上来存储到SIEM里，对分析攻击场景有很大的帮助。 不过，国内的一些安全厂商对SOC输出没有标准，导致搜集的日志格式不统一，后面的关联分析达不到用户需求，最终80%的SOC的项目都以失败告终。 那么新的态势感知相比SOC平台有哪些不同呢？ 首先是检测引擎，安全探针要提升自身的检测能力和准确性。主机层面通过在终端安装EDR产品或者下一代杀毒软件，进行搜集比较准确和简单关联的日志，利于更好地检测安全威胁。网络层面通过NTA（全量日志分析产品）来匹配危机情报和沙箱等新技术进行分析。web层面也会有基于语义分析的WAF日志，这样收集对关联分析起到很大作用，达到检测层面的提升。 其次是大数据架构方面的提升。由于现有的SOC平台用传统的MySQL和Oracle来进行关联分析，这种关联分析的技术扩展性相对较差。所以随着大数据技术的发展，搜集的时候用Flume，存储的时候用ES，在关联分析的时候用Spark，达到大数据云架构的改变。 最后是在云上更有优势。可以高度规划实时的采集日志，并且通过Kafka这种方式发送到态势感知的安全操作中心，这样在以后的关联分析时就占有了主动权。基于这些因素，才让态势感知产品出现。随着技术的发展，态势感知会继续往下发展，下一个极端是基于安全运营的SOC，比上一代的威胁感知SOC多了基础日志收集丰富程度。通过智能分析架构来做处理，例如机器学习、图分析等技术。 02态势感知技术的发展趋势态势感知首先通过网络层面进行决策，通过搜集了大约十款产品来进行调研分析，发现网络层面的能力主要有核心能力、扩展能力和增强安全运营能力。 态势感知的核心能力包括持续抓包取证、流量/威胁可视化、网络入侵检测系统规则匹配、WebIDS规则匹配。扩展能力主要体现在威胁情报、动态行为检测和机器学习自动检测引擎，机器学习自动检测引擎里面又分为分类分析、聚类分类和KDE时序分析。 增强安全运营能力就是对安全实体进行分析，通过分析探针来查看攻击的用户，比如SOAR、Kill-Chain、UEBR。而态势感知在主机层面上的能力，除了有核心能力、扩展能力和增强安全运营能力外，还具有未知威胁检测能力。 针对于云上，态势感知的核心能力主要是做云工作的负载肩负，包括配置/漏洞管理、网络隔离防火墙流量可视化、系统完整性测量认证和监控、应用程序控制、补充性内存和漏洞攻击防护。 扩展能力中的行为监控HIDS/EDR能力是云端主机层面防护软件中最重要的，其它还包括静态加密KMS、HIPS漏洞屏蔽、欺骗能力和反恶意软件。增强安全运营能力包括工作负载外部的漏洞和配置评估、IAM/MFA、日志管理和监控。未知威胁检测能力需终端集成威胁情报、AI/沙箱云查杀。 03京东云态势感知功能优势 京东云的态势感知产品可帮助用户进行大数据安全分析。最底层是基础数据层，进行NetFlow搜集、网络流量、DNS、HTTP/S日志收集。第二层是威胁感知层，通过安全的探针检测，包括DDoS/高防、全量日志分析、NIDS、威胁情报匹配、机器学习异常检测、沙箱、主机安全/EDR和漏洞扫描/蜜罐里的数据都搜集上来。 第三层是关联分析层，包括实时针对性攻击分析、APT攻击分析、自动化编排研判、精准画像UEBA和图分析。针对性攻击是在一分钟之内发现了攻击的关联分析，而APT攻击会把攻击时间相对拉长，拉长成一小时或者一天的时间，给黑客足够攻击时间，便于检测黑客攻击的情况。 自动化编排研判是目前比较好的解决方案，由于黑客的攻击手段千奇百怪，只能更细化调度的引擎，细化到每个功能点像积木一样组合在一起，形成关联链。通过关联链更好的去分析、丰富查询关联分析的过程。 而UEBA主要是针对云上的数据，以数据层面来进行切入，比如说OSS、RDS或用户自建的数据库对它进行监控，包括用户对数据库的访问、对象存储的访问进行分析。底层的（OpenAPI）的访问也都会进行关联分析或机器学习分析。 图分析是在主机层面检测信息、网络信息、用户信息可以用图的方式展现给用户，可以挖掘出攻击的路径，是一种很好的分析手段。 第四层是威胁展示层，主要是通过告警事件、威胁事件、热点事件、安全大坪、自动化攻击溯源给用户展示，降低用户调查取证的时间，提升效率。 通过云上日志可以分析出更有价值的安全威胁以及安全问题。 底层基础网络信息是五元组、DNS、HTTP、LB信息，在攻击路径的时候可能会通过NAT的转换，转换之后便不可查找主机ID。同时，NAT数据可用于对资产进行再补齐。通过VPC Log获取VPC里数据流传输，还可以分析出横向攻击。 在主机基本信息中，通过上传的进程、端口、账号、软件、文件、系统日志，关联出更有价值的信息。比如说异常网络连接、肉鸡行为、可移操作、敏感文件篡改都可以进行分析。安全产品例如Anti-DDos、WAF、扫描器、HIDS、NIDS、数据库审计、堡垒机都可以上传。有利于分析DDoS攻击、Web漏洞、SQL注入、病毒木马等。 云产品组件的云产品基线，配置失败可能引起的漏洞；还可以对OSS审计日志、RDS审计日志、OpenAPI日志的风险访问行为进行分析。还有人员信息中的VPN、登录日志和权限日志。这些都可以帮助态势感知更好的进行分析。 04云态势感知技术攻击链分析攻击链分析分简单规则关联分析和复杂规则关联分析。 云态势感知技术的计算层采用Spark，这样数据分析产生的警告会随着时间流入到大数据处理引擎（Spark）里，通过Spark里的滑动窗口对所有输入的数据流来分析。遭受到暴力破解并成功，第一个从网络的IDS会产生警告，接下来会有EDR告警，同时安装系统后门。整个操作是连贯的，这便是简单规则关联分析。 那复杂规则关联分析是什么样的呢？首先黑客会使用扫描集群，扫描RDS端口进行暴力破解。如果未授权访问上控制云服务器的基础服务器，便会将公钥写入基础服务器，之后就能自动化操作，比如说装一些黑客工具、DDoS工具或挖矿、勒索工具。 恶意服务器长时间扫描会被威胁情报检测到服务器的IP地址，然后态势感知在本地检测的时候会对这些IP进行扫描。在扫描暴力破解的时候，利用NIDS ET规则来进行检测，接下来会用Redis弱口令/开启认证，口令是弱口令或者没有开启认证，会产生告警事件。写入C&C服务器公钥的时候会使用sshkey目录，在动目录的时候会产生一条非法文件篡改的告警事件。 再往后会有反弹shell，可以对可疑连接或者是失陷主机主机进行检测。在挖矿程序的时候我们会通过云沙箱来进行检测，DDoS也可以通过肉鸡行为进行检测。这样对用户每一步操作都形成了告警事件，然后把这些告警事件关联在一起。这就是比较复杂的规则和时序分析的过程。 05云态势感知技术机器学习&深度学习分析异常检测是怎么做的呢？这里以DGA检测为例。首先要把外部训练数据导进来，有黑数据和白数据，然后把DNS的数据导进来进行特征提取，再往下是用Spark训练模型，训练之后会把模型放在集群里面进行检测，这样就形成了DGA运行检测的流程。 那么模型做好之后怎么用呢？ 首先检测通过两条路，第一条路是NIDS的DNS流数据，通过程序补齐账号之后发到Spark里面进行特征提取匹配，然后进行预测；第二条路是云主机上，比如说自己设定了公网DNS解析的话，它发送的数据也是通过DNS解析来进行补齐资产来进行实时检测。 通过这两个数据会把DGA预测做一下，之后把数据放在实时管理分析引擎中进行分析。分析之后才会把它放到ES topic里面，给用户看到最终的分析结果，这样就实现了DGA域名检测流程。 图分析技术就是把所有的数据导到图分析，通过图的方式关联出来，再通过图的搜索算法检测出来。例如下面这个真实的入侵案例； 首先通过挖矿进程发现其中有一台服务器（Test-001）已经高负载，查看高负载CPU所定义的进程的时候，发现它是一个异常进程，所以进行告警。告警之后会进入到观察列表里，通过某个点找出挖矿进程的程序是怎么运行起来的，又是怎么进到服务器里的。 通过时间推移的方式，通过上下文关联来进行检测，关联之后发现了一条命令行审计规则，也就是通过其中一个可疑进程来下载了挖矿的脚本并且运行了。挖矿脚本的副进程是用户自己创建的一个Hadoop的进程，也就是Yarn进程。Yarn进程其实是Hadoop未授权访问的RCE的漏洞。同时通过扫描器来进行扫描检测这台主机，发现这台主机确实存在Hadoop RCE的漏洞，这便是自动化攻击溯源，里面的核心技术就是图分析的技术。 目前京东云态势感知产品的应用场景一个是公有云市场，另一个是专有云市场。专有云市场所对应的产品有态势感知JDStack版本，是内嵌到专有云的云租户来进行检测，它的用户是对于里面每一个租户安全的检测。还有一个是针对于云平台，或者针对与IDC传统的安全管理场景提出产品叫态势感知专有云的版本。 点击“京东云”了解京东云态势感知产品

世界在变，技术在变，需求在变。 唯一不变的是变化。 面对变化，技术人如何在不确定性的世界中寻找最优解？ 查理芒格说：“掌握一定数量的思维模型，能解决这世上90%的问题。”与其在重复的“增、删、改、查”中消耗能量，不如培养举一反三的能力。在不确定的社会中用尽可能小的消耗，找到最优解决途径，做尽可能多的事情，撬动尽可能大的资源。 今天，阿里技术公布一波阿里P8、P9技术大牛的思维模型，将他们的思维模式呈现出来。你可以在阿里资深专家职业生涯的真切感悟中，找到应对危机的最佳方法。《阿里工程师的自我修养》现已正式公开，可免费下载阅读。) 从入门到进阶，从普通员工到主管，从知识到落地，从量的积累到质的飞跃，在不确定性的世界中，你遇到的种种难题，阿里工程师正在探索着最优解。 3大思维、10个技巧、10年感悟……每经过一次大的战役，阿里工程师都会复盘、沉淀，这些经验值得细品。 与其临渊羡鱼，不如退而结网。 在不确定性的世界中，如果，你还心怀梦想，偶尔停一停，修炼大脑、培养思维。停下来不是放弃，而是为了走得更远。就像，蹲下来后才能跳得更高，对吗？ 本文作者：阿里妹阅读原文 本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

去年七月份离开了上一家公司，在那里度过了对我职业生涯来说至关重要的4年。期间遇到了很多给我巨大帮助的朋友，我感觉除了技术的提升，心智上也得到了成长，也从最初的一枚菜鸟慢慢成为能够独当一面的团队骨干。在后期也开始接触一点点管理，主要是带新人。因为难度不大，并没有什么积累，更谈不上什么管理经验。来到现在的公司之后，才开始正式接触管理，一年多的时间里遇到了各种各样的状况，也解决了形形色色的问题。主要想从我个人的角度出发，记录一下自己在这一年多的时间里的一些感悟。 一、转换角色因为确实没有什么管理经验，入职后我给自己提了个要求：坚持不定期地和老大主动沟通。有一次和老大面谈时，他问了个问题：为什么感觉你们团队只有你自己总加班，其他人并没有那么忙？我才忽然意识到自己这个问题。不得不承认自己当时仍然停留在团队骨干的阶段，分析了一下原因，主要有两个： 原因一：对团队不足够了解，不足够了解就很难充分信任。当有一个需求时候，尤其是较为紧急和复杂的需求，内心会纠结：交给他会不会有问题？他能不能按时搞定？我自己做是不是更有把握？这种纠结一旦出现，最终结果往往是：算了，还是我自己来吧。在公司的起航培训时，老师说这种现象在刚开始接触管理的人群中非常普遍，它的后果也很明显：自己累，同时也剥夺了他人成长的机会。我后来经过一段时间思考后，采取的解决办法是对任务拆分，既然觉得整块交出去有风险，那就通过拆分来分解风险。随着对团队的熟悉和团队成员的自身成长，拆分的粒度慢慢放大，直至每个人都能独立负责一整块需求。现在团队的每个妹子基本上也都达到了这个要求。 原因二：不好意思给他人分派工作。在团队成员手里有需求的时候我的这种表现尤为明显，后来我分析了一下，完全是一种不自信的表现。其实，只要把需求排期控制好，即便是有需求重叠，我们通过均衡每个人的任务队列，正常分配即可。如果仍然有疑虑，可以通过不定期沟通来确保任务的进度。 把自身定位思考清楚本身就是一件很难的事，想要及时的感知变化更加困难，但旁观者清，身边的同事绝对是我们最好的帮手。及时收集反馈，非常有利于我们自身的改善。 二、完成需求 VS 把事做成这两者的区别还是非常大的，尤其是经过这一年多的时间，感觉愈加明显。 完成需求，是从一个开发者的视角来看，对自己最基本的考核标准，也是整个的开发过程（需求讨论、开发、测试、上线）中的其中一环。 把事做成，则要求跳出开发者的角色限制，从整个需求层面有一个宏观的把控，而不应该把视野局限在自己仅仅是一个前端或者后端开发者的身份。 记得年初做主站前端重构，这完全是一个技术自发的需求。我当时作为需求发起人，保证前端重构开发的完成是我最基本的工作，同时还需要申请产品资源作为业务支持，协调后端对模板变更，以及申请测试资源确保上线前的质量，甚至于包括后期灰度计划的制定和推进。在这个过程中，深刻地体会到了owner的含义，当你把目标集中在如何把事情做成的时候，中间每个环节都是你要负责的部分，这比单纯的完成需求难度要大很多。另外一方面，当想着把事情做成的时候，中间的过程是否要严格按照流程就显得没那么重要了，比如申请产品资源受阻时会立马调整策略：自行梳理问题后找产品确认，无需产品同事的全程参与。还有非常大的一点感悟：在大公司环境下，大家互为资源，如果想把事情做成，协调能力是非常重要的一项技能。 上面的例子是技术发起的需求，其实对于日常的产品需求，也可以试着打破对自己身份的限定。在整个过程中，只要发现有任何不合理或者值得改进的地方，作为参与其中的一份子，都应该及时发声，提出自己建设性的意见，比如这个需求点是否符合用户预期，接口这样设计是否便于以后扩展，返回的数据结构是否可以整合等等。大家都本着把事情做成的态度，对于这样的参与热情，相信不会有人忍心浇凉水。 三、一定要做时间管理随着负责的事情越来越多，每天戴上耳机安心敲代码已成为奢求，总会被各种排期、需求评审、技术方案讨论打断。曾经有一段时间，感觉整个人都有一种撕扯感，被折磨的焦头烂额，但一天下来又感觉什么都没干，尤其是这一天没怎么写代码的时候，焦虑倍增。痛定思痛，感觉自己的时间管理应该是重点思考的事情了。结合以前的工作方法，我做了一些整合，以周为单位，把每天的事情通过表格的形式罗列出来，包括具体实施时遇到的问题等，具体如图所示： 慢慢的我发现自己已经成为了笔记的重度依赖者，当然，这没什么不好，好记性不如烂笔头嘛。一个非常大的好处就是，这每一周的记录都是阶段性总结最好的素材。不过，利用笔记最大的收益还是做到了对事情有规划，这一点非常重要，无论生活还是工作。 还想说的一点，当开始接触管理之后，可能代码的输出不再是衡量工作的唯一标准了，所以，有时候一天都在参加会议或者培训，只要这些事情在规划之列，那就无需纠结，按计划执行即可。 四、技术仍然是安身立命的根本每个做技术的人应该都听过这句话，说白了就是告诉我们：一定要把自己吃饭的硬实力整上去。 当作为团队主力时，提升技术才能保证我们高质量地完成需求，同时也能给身边的人提供一些技术支持。作为团队负责人的时候，除了给自己的团队成员提供技术支持之外，还要为团队提供技术方向的引导，以及对团队的技术水平负责，另外，团队的技术氛围也很大程度上取决于团队负责人的技术水平。 可以说，虽然我们处于不同阶段时，技术对我们的作用不同，但从我们自身的价值来说，技术始终是第一位的。 基于我的观察和经历，我觉得：对于技术领域的管理，技术好不一定能做好管理，但技术差一定做不好管理。 技术领域的管理还是非常需要硬实力支撑的，正所谓“一将无能，累死三军”。所以，目前为止，我还是要求自己一定要坚守技术，极力避免出现吃老本的不堪境遇。 归纳一下，这里主要是想阐述：接触管理之后并不意味着技术相比于管理经验不再重要，相反，管理岗位对技术的要求更高了，我们应该始终坚守技术带领团队成长。 五、持续学习上面说了硬实力的重要性，其实除了在自己的专业领域持续学习打造硬实力之外，还应该适当扩大自己的技术视野。 技术领域有那么的多方向，我应该学哪些？学到什么程度？这些问题曾一度困扰着我，不过，后来我思考了一段时间之后，给自己定了个准则：凡是自己工作中接触到的但还不了解的，都应该在学习范围之内，至于掌握程度，取决于和自己专业的密切程度。 前端开发日常接触最多的就是后端了，其中涉及到接口的设计、数据库的存储逻辑、后端缓存的原理、nginx的原理和配置等等。如果掌握了这些，对于我们制定和评判技术方案有非常大的优势。举例来说，网站用户登录态是个非常常见的问题，但我发现有很多同学对维护登录态的原理不很清楚，对前后端的边界有点模糊，以至于出现前后端都要维护cookie的现象。再比如，如果我们掌握了nginx的基本配置，完全可以在本地模拟线上域名，对于一些和域名相关的自测在本地就能搞定。 曾经和一个面试官讨论过为什么现在的前端岗位或多或少都要求一点后端的技能或经验，他给出的观点是，这样的同学面对整个系统时看到的层次更深，我对此深表赞同。 另外，测试领域的一些思想和方法也非常值得我们学习。我们的自测很多时候都是跑通就行，其实我们提测前用测试的思维思考下，能够规避掉很多问题，比如说场景法测试、边界值测试等。 除了学习后端和测试领域的一些技能外，学习一些与人打交道的软技能也非常必要，比如沟通、协作以及寻求资源。软技能的学习要比技术的学习更复杂一些，没有统一的标准，每个人的风格又不一样，所以更多的需要我们自己去多总结。我觉得软技能的唯一衡量标准：是否有效。所以，无需过多纠结于细节，有了想法就去验证，然后再根据反馈的结果及时修正，这样就能快速建立起自己的一套软技能体系。 至今还记得以前的老大曾说过的一句话，大意是：在学习方面，现在的投入未必会立马收效，但在将来的某一天终将受益。 六、最后以上都是我接触管理以来的一些感悟，最后还想说一下现阶段对管理的认识。我觉得自己现阶段的任务就是能够带领团队前进，如何才能做到呢？我总结了一下，就是“信服”二字，可以拆开来看： 信即信任，关于信任在团队中多重要感觉无需赘言了，主要想说一个关于信任的客观规律：可能需要做好一百件事情才能建立信任，但毁掉信任可能只需要搞砸一件事情。这是我亲身经历后最深刻的感受，所以，对于别人的信任要心存敬畏。 服即服众，一方面体现在团队负责人必须以身作则，无论是对技术的追求，还是对约定的遵守。另一方面体现在团队负责人的硬实力上，当然，这并不是意味着团队负责人的每一项技能水平在团队中都是最高的，但团队成员需要帮助的时候，必须要给出行之有效的解决方案。 感觉管理是一门非常高深的学问，之前也尝试过找一些关于管理的书来读，可能是自己水平有限，完全没有任何应用，甚至都不如一场面对面的公司培训来的生动。目前的主要学习方式还是多观察，多思考，然后多尝试，期待自己有更进一步的提高吧。

都说 Intel 第八代 CPU 对比上代是牙膏不小心挤多了，而配备第八代 CPU 的 MacBook Pro，只有 Touch Bar 版本，虽然贵了一点，但就一个字 —— 买！ 收到电脑后，兴冲冲地体验了一把 Touch Bar，真的很有新鲜感！前提是你是一个影像工作者。 然而随着时间推移，我的 Touch Bar 渐渐地变成了一个耗电的无用配件，还时不时地误触到「Siri」按钮。只有当我调整音量或亮度的时候，我才会有意识地使用 Touch Bar，让我多花的钱，显得有那么些意义…… 可是今天，我发现了一款让 Touch Bar 废物利用的方法了！ 有人开发了一款 macOS App，可以把 Touch Bar 当作「Dock」，直接用来切换和启动 App，叫：Pock，还是开源的。 笔记本的屏幕其实是不够用的，Dock（程序坞）又会让可视面积减少一截。虽然可以隐藏 Dock，但来回唤出也挺麻烦的。 想要最大化屏幕空间利用但又不喜欢自动隐藏 Dock？试试 Pock，把 Dock 放到 Touch Bar 上，好好利用一下这块触控屏。 Pock 具有以下特性：*支持显示通知角标*提供了 ESC 按钮，所以不必隐藏 Pock 来使用系统的 ESC*可设置是否在进入系统时启动 Pock 很久以前 macOS 就把应用程序的菜单栏放到顶部状态栏，现在 Pock 把 Dock 放到 Touch Bar 上，是不是挺对称的？Pock 会保留应用图标的小红点，这样你就不会错过重要的通知信息。亮度、音量、播放之类的常用功能键也都在，用起来很方便。 如果你有一个带 Touch Bar 的苹果电脑就可以体验啦 ~ ...

继《Nervos 与火币联手打造金融公链》新闻发布后，我们马不停蹄开启了新一轮人才招募计划。区块链开发工程师们、以及有志于投入和钻研区块链开发的，请瞄过来！加入我们，一起开启区块链工程实践的黄金时代！ 什么是区块链开发十年间，区块链从 1.0 发展到了 3.0，从点对点的电子现金到智能合约再到扩容解决方案的实践，区块链技术的不断进步让我们相信一个更加美好的新时代已经来临。 区块链技术设计密码学、经济学、共识算法、P2P 网络、数据存储等多领域。作为一种革命性技术和新的发展领域，区块链为开发者和技术爱好者创造了新的就业机会。 区块链开发主要分为两个主要模块：核心区块链开发和区块链软件开发。核心区块链开发人员主要负责开发区块链系统的架构，如何设计协议，共识协议的设计以及与区块链技术相关的其他高级决策和开发。而区块链软件开发人员使用 Core Blockchain 开发人员设计的架构和协议来构建在区块链技术上运行的去中心化应用程序。 关于 Nervos NetworkNervos Network 是由 Nervos 基金会成立，通过一层公有链协议 Nervos CKB 保证网络的安全性与去中⼼化，二层协议提供具有可扩展性的交易和计算服务，以及多个应用层协议衔接商业场景。 2018 年 7 月 Nervos 完成 2800 万美元的融资；2018 年 11 月，Nervos CKB 代码开源；2019 年 5 月，CKB 测试网正式上线。 Nervos 的工程师们Talk is cheap，show me the code。Nervos 的开发团队是一群热爱开源的 Hacker，他们希望用最简单的代码解决问题，但简单并非容易。20 多位开发者在 400 多个日夜、5 次封闭开发，将 Nervos CKB 测试网呈现。 开发团队有着深厚的区块链技术研发和开源精神 首席架构师谢晗剑（Jan）曾是以太坊（Ethereum）核心研究团队唯一中方成员，与 Vitalik 一起从事以太坊的早期 PoS 协议和 Sharding 方案的研究，实现了以太坊 PoS 的早期原型。他设计与开发了世界上第一个开源数字货币交易所 Peatio 以及世界上第一个使用微服务架构的开源企业区块链内核 CITA。 ...

近日，网易云官网放出消息，网易云创峰会（yc.163yun.com）将于7月26日在杭州钱江新城万豪酒店举行。据悉，本次大会以“连接·洞察·进化”为主题，从官网内容上看，今年的云创峰会将重点聚焦微服务、大数据、人工智能、物联网和中台等前沿技术的聚变效应和应用进展，探究制造、零售等领域的最新实践，促成整个社会经济的跳跃式进化。为了让大家对本次大会有更深入的了解，这里为大家总结了大会的3大亮点。 亮点一：网易云将重磅发布全链路产品，或将包含中台解决方案 首先看最能体现公司动向的新品发布。议程显示，这场峰会将有全链路大数据产品和轻舟微服务产品的发布，而大会亮点则体现了全链路中台方案的发布。 最近一年，“中台”在业界广受热议，不同企业对中台的理解往往大相径庭。业界讨论的不外乎技术中台、业务中台和数据中台等几种类型，而网易云在这些方面也早有布置。 从技术中台看，在2018网易云创大会上，网易云发布了全栈化的微服务解决方案——轻舟微服务，覆盖架构演进的所有问题，为业务研发提速。德邦快递则分享了借助轻舟微服务实现“薄前台、厚中台、慧后台”架构升级，建成业务中台和数据中台驱动业务创新的经验。此后，网易云多次释放了轻舟微服务支撑业务中台建设、加速数字化创新的核心观点及实践案例。所以，我们有理由相信，轻舟微服务产品升级的背后，将是业务中台战略的升级。 大数据方面，2018年，网易大数据发布了一站式大数据管理和应用开发平台（网易猛犸）和企业级可视化分析平台（网易有数），经过不断的业务实践和产品迭代，网易大数据整合了更加全面的数据技术能力和产品技术能力。此次云创峰会，网易大数据打出了全链路大数据产品的名义，足见其提供整体解决方案的雄心。那么，从大数据平台到数据中台的升级，也是负责任的猜测了。 从全栈微服务到全链路中台，从技术中台到业务中台+数据中台，网易云还是守着网易公司匠心和创新的风格。然而，强调“专注企业数字化未来”的网易云，对中台是如何理解的，其全链路中台解决方案形态与内涵有什么不同，这些差异性对企业数字化转型升级而言又意味着什么，值得业界关注。 亮点二：数字技术核聚变悬念迭起 从场景化云服务，到全栈微服务，再到全链路产品，网易云发布新产品的逻辑，也许从大会的另一个信息可以猜测一二——网易云今年提出了“技术核聚变”的理念。 大家知道，太阳就是通过核聚变为万物生长提供光和热的，对于专注企业数字化未来的网易云而言，“技术核聚变”自然是要为企业数字化提供源源不断的能量。从场景化云服务，到全栈云计算，再到技术核聚变，可以看到网易云本身的蜕变。 从促进企业数字化转型升级的角度，哪些痛点可以借助“技术核聚变”的能量来治愈？这些痛点需要什么样的“核燃料”？这些“核燃料”的反应该如何掌控？技术核聚变中，全链路中台的意义又是什么？这些都是很有趣的话题。但网易云会给出什么样的答案，值得期待。 去年网易云创大会，网易副总裁、网易杭州研究院执行院长汪源提出了“开放开源”的技术理念，认为这是企业数字化的最优路径。如今该理念的正确性已经被验证——最近一年，各个云服务商都在开源项目上投入了更多的人力财力物力，苹果公司也加入了云原生计算基金会（CNCF）。由此看来，本次云创峰关于“技术核聚变”的各种悬念，又要圈粉了。 亮点三：智能制造加码企业进化之路 网易云官网还透露了一个成立智能制造联盟的消息，这也值得玩味。 时至今日，IIoT（工业物联网）获得了更多企业的理解，5G也牌照业已发放，正式商用在即，这些成果能否真正作用于工业？去年网易云创大会上，汪源曾提出，数字经济能产生最大价值的是制造业，只有制造强，中国才能成为强国。那么，经过一年的探索，网易云在智能制造领域又有哪些新的进展？这个智能制造联盟的成立，又是带着什么使命？要解决哪些问题？一切的谜底，还有待峰会当天揭开。 目前网易云创峰会官网（yc.163yun.com）已经开启报名。

为帮助开发者们提升面试技能、有机会入职阿里，云栖社区特别制作了这个专辑——阿里巴巴资深技术专家们结合多年的工作、面试经验总结提炼而成的面试真题这一次整体放出。并通过这些笔试真题开放阿里巴巴工作机会，让更多的开发者加入到阿里这个大平台。 这一次，不仅是知识的收获，还将间接地与技术大牛们做了直观的沟通，了解他们的出题思路与考察要点，并加以消化吸收，这对自己技术能力本身就是一种极大的提升。走上编程之路，不断丰富自己方能与世接轨，努力做最优秀的自己。 点下方阅读原文下载试题及答案！ 本文作者：山哥在这里阅读原文 本文为云栖社区原创内容，未经允许不得转载。

作者：WeTest小编商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/459.html WeTest 导读TesterHome 联合腾讯 WeTest 出品 MTSC2019 重磅游戏测试 Topic ，首次公开揭秘腾讯亿级用户游戏背后的质量保障 QA 黑科技。_ 2019 年，中国游戏行业正式从“流量红利期”进入“质量比拼”阶段：一方面，游戏市场同比增长率显著放缓，另一方面，用户对游戏创意、审美品质和游戏体验要求却在迅速提升。 游戏精品化已成为行业必然趋势，这对优质游戏背后的软件测试和质量保障也提出更高要求。 移动游戏测试的难点和痛点和其他软件测试相比，移动游戏应用不仅生命周期短、迭代速度快，程序逻辑也更复杂，对逻辑流时序性要求更严格，另外，功能测试任务繁重也导致在黑盒测试之外，企业必须具备强大的自动化测试技术和质量监控工具，才能满足业务需求。 腾讯 WeTest 通过腾讯大数据及第三方数据平台进行了深入的数据采集和分析，总结了当前中国移动游戏研发和测试面临的几大最常见挑战： • 兼容性问题：平均每次测试能够发现游戏产品拥有 10.1 个兼容性问题，其中，显示异常、Crash 问题占比超过 70%，另外，功能问题亦占比 14%，尤其是“刘海屏”、“全面屏”等异形设备带来 UI 异常问题频发；• 客户端性能：登陆、卡顿、掉线、更新、下载、安装、启动、硬件（CPU、内存）和兼容等直观问题最受用户关注；• 服务器性能：海量用户、高并发实时数据计算以及网络环境等综合因素对游戏服务器性能带来众多挑战，比如最火爆的战术竞技游戏，通常采用 UE4 引擎机制，战斗服会承担大量同步、物理、逻辑等计算。• 安全性测试：定制外挂、通用修改器，刷道具等在强交互性游戏中屡见不鲜，手游质量保障对安全漏洞必须未雨绸缪、防微杜渐。• AI 等高新技术应用：如何利用 AI+ 大数据技术提升游戏测试和质量管理水平？如 AI 测试算法设计、AI 与人工测试的配合、与自动化测试的整合等。 以 MOBA 手游代表王者荣耀为例，在海量游戏用户和日活背景下，以上挑战都加倍放大，互联网游戏企业该如何构建质量保障体系，应对游戏测试难题？ 腾讯首次揭秘游戏质量保障体系TesterHome 联合腾讯 WeTest 邀请到腾讯互娱天美工作室群（TiMi Studio Group）质量管理中心测试总监楚培林及团队核心成员在 MTSC2019 第五届中国移动互联网测试开发大会上分享腾讯亿级用户和日活背后的游戏质量保障体系和测试技术！ 没错，就是负责王者荣耀、绝地求生全军出击、天天爱消除、穿越火线手游、QQ 飞车手游等游戏质量保障的 QA 团队。 另外，也有幸邀请到腾讯互娱光子工作室群（Lightspeed & Quantum Studios Group）游戏测试总监邱广分享大型游戏项目的质量管理实践心得，以及腾讯互娱品质管理部图灵工作室（Turing Lab）总监张力柯分享人工智能在游戏评测、快速定位 UI 画面质量问题上的最佳实践经验。 议题内容将涵盖游戏测试质量保障体系建设，MOBA 手游、FPS 手游、以及灰盒测试、AI+游戏测试等专项议题，具体信息如下： ...

阿里妹导读：在历史文章《如何成为优秀的技术主管？》中，阿里巴巴高级技术专家云狄从开发规范、开发流程、技术规划与管理三个角度，分享对技术 TL 的理解与思考。今天的文章，他将继续深入探讨这一话题，从管理的角度分享技术TL的核心职责，主要包括团队建设、团队管理、团队文化、沟通与辅导、招聘与解雇等，希望与大家共同探讨、交流。背景互联网公司的技术团队管理通常分为2个方向：技术管理和团队管理，互联网公司的技术TL与传统软件公司的PM还是有很大的区别，传统软件公司的PM更多注重于对项目的管理包括项目任务拆解、项目进度以及风险等。对于多数互联网公司而言，技术TL更多的职责不再局限于项目角度，而是对业务与技术都要有深入的了解，就像黑夜里的灯塔，能够引导和修正团队成员前进的航向。综合技术和业务角度去深度思考问题，具备一定的前瞻性，并在技术领域投入持续的学习热情，向团队成员传道，补齐短板，提高整个团队的战斗力。技术TL职责不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗，另外一多半的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，剩余的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人做出不平凡的事。”然而，不是任何一群平凡的人聚集到一起，都能做出不平凡的事。甚至一群优秀的人聚集到一起，也可能只是一个平庸的组织。大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。领导者是一个组织的灵魂，领导者在很大程度上决定了组织所能达到的高度。阿里有句土话“平凡人、非凡事”，技术团队同样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工作结果带来决定性的影响。其实每个公司、每个团队的背景不太一样，从管理学的角度探讨一些问题，没有统一标准的答案，本文中一些观点仅是个人观点，更多从我个人成长为技术TL一些观点理念，同时我也是吸取了前辈们一些优秀的管理理念，包括我最为尊敬的通用电气CEO杰克·韦尔奇、苹果CEO乔布斯、Intel CEO格鲁夫，国内我最推崇的技术管理者robbin（丁香园的技术副总裁）。团队建设从2014年开始带这块业务技术团队，至今有5个年头。回想起来，团队管理中所有能遇上的问题都遇到过了，其中的磕磕绊绊数不胜数，完全是在实践当中吸取教训，团队建设这块在这里和大家简单分享一下，当然这里面也有做得不够好的地方。在阿里每个人都能感受到拥抱变化，基本上每年组织架构都会调整，甚至有些团队每半年都会调整一次。14年我也算是被分配到这个团队负责这块业务，这块业务是集团收购一家子公司的业务，整个团队文化和技术体系与阿里有很大的差异化。一般来说新官上任三把火，新的技术TL空降之后往往会大肆招人，快速推进改革,而且有些技术TL喜欢把原来的一些旧将搬进来。当时我没有急于这么去做，没有招过一个新员工，而是立足于稳定现有的团队，主要基于以下原因：团队和业务了解不够深：对于目前的团队的人员以及业务，我不够了解，不清楚这里面有哪些坑和陷阱，一旦初战不利，领导的信任度被透支，在公司恐怕难有立足之地，更不用谈论改造团队，发挥自己的才能了。流程与制度：针对团队现状存在的一些问题，我初步判断并不是人的问题，很多问题是一些组织、流程、制度上的问题。我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾之前招聘新人，不但不会带来新的生产力，反而会造成团队的混乱，应该先打下一个好的根基，再招人，才能事半功倍。团队安全感：不想让团队现有的成员感觉一朝天子一朝臣，担心自己在团队中会被边缘化，成为弃儿。另外一方面能够让现有团队心理比较安全，可以安心地好好工作，不至于发生更多的动荡。经过了几个月的摸底了解，大概清楚当时团队存在的一些问题和原因：业务配合不规范：产品、运营、研发部门之间配合没有建立合理的工作流程，比如对于产品需求的PRD评审没有标准，对于运营需求没有量化指标，大家都是疲于奔命做需求，导致大家的积极性不够高。跨团队协作混乱：跨部门之间的工作配合毫无规范可言，部门之间相互推诿，随便什么业务人员都会随时给研发人员下命令，长此以往，伤害了研发团队的积极性。针对以上问题，我主要把协作流程规范梳理了一番，制定了相对合理、规范的产品合作流程，同产品同学约法三章，明确了PRD输出的标准和规范，运营的业务需求也统一由产品输出，杜绝一句话需求。同产品、前端、UED、QA团队的协作统一标准流程，下游对上游依赖方输出的工作必须有明确的标准规范，口头说的统统无效，拒绝合作。针对跨团队协作乱的情况，我特别想说明一下，由于研发部门不是直接创造收入的业务部门，而是承担业务部门的服务者角色。作为一个服务者，往往站在一个被动和弱势的位置上，很容易被业务人员举着收入的大棒指挥你无条件的服从。业务部门人员随便指派任务，随意变更需求，团队同学无所适从。这样一来，部门内部无论怎样合理的计划都会被外部的力量轻易打破，让团队同学无所适从，导致大家的工作积极性不高，喜欢互相推卸责任。久而久之，员工就产生了自我保护意识，凡工作尽量往后退，凡责任尽量往别处推，不求有功但求无过。为打破员工养成的这种自我封闭的保护意识，鼓励员工更加积极主动做事情，我能够做的就是把这些责任都扛在自己身上，亲自去协调每项工作，让团队成员没有后顾之忧，让团队同学相信我可以搞定他们担心的事情，出了任何问题我可以来背锅，给自己的团队创造一个相对宽松和自由的工作空间，保护团队不被外部的各种杂事伤害到。团队管理人往往会高估自己而低估别人，很多管理者都会觉得手下交上来的工作做得不够完美，这里考虑不周那里做的啰嗦，但很多时候你只是看到了他人不擅长的地方，或者只是对方和你的出发点不同给出了不同的解决方案而已。很多时候，我们并不如自己想象的那么强。管理者在充分理解一些管理的理念之后，不断地在实际的管理工作中去实践并收集反馈和迭代，这样才能够形成自己的管理风格，并找到最适合当前团队的管理方法。作为一个团队的管理者，通常会有两种风格管理策略，简要概括为集权式的管理风格、放权式的管理风格。集权式管理：管理者的风格是偏细节的，定义清晰的工作目标，并且把工作目标分解得非常细致，让手下的团队能按照整个计划步步为营往前推进，这是一种风格，相对来讲比较集权。可以说我带这个团队的第一年是这种风格，我甚至会参加每一次需求评审，无论需求大小，会和研发同学一起去写代码，对研发团队我会做详细的code review，亲自带领研发团队做技术交流和分享，参与技术讨论确认架构方案，这样以来和大家建立起了充分的信任。放权式管理：定义大的目标，把握大的方向，做关键性的决策。但是并不深入每个细节去管控手下团队的执行细节，以结果为导向。我到这个团队一年后，业务流程已经清晰的建立起来了，骨干员工在业务上能够完全领会并且达到我的要求，这个时候放权可以充分调动团队的自主性和创造性，多数技术人员他们喜欢被领导，不喜欢被管理。以上这两类管理风格没有对错之分，究竟哪种方式更适合完全取决于团队的状况。其实这里我更想说一下关于放权式的管理风格，对于一个制度刚刚建立，流程还没有跑顺畅，团队残缺，骨干员工业务能力不及格的团队，采用放权式管理是错误的。你必须事无巨细，从第一线的业务细节抓起，手把手的带员工，教会他们怎么正确的做事情，怎样达到你的要求，手把手的培养业务骨干，搭建团队核心架构。这些年我看到过太多的案例，管理层自己从不真正深入业务，也缺乏对业务的深刻理解，没有找到问题的本质原因。总是寄希望于招人来解决问题，结果换了一茬又一茬人，问题永远解决不了，而且从来不深刻反思自己是否亲自尝试解决业务问题。很多时候架构反应出来的问题，其实是组织、流程的问题。总之，作为管理层，如果自己没有深入一线去发现问题，自己动手去解决问题的决心和勇气的话，那这个团队很难有新的突破和成功。团队文化在我刚参加工作的前几年，就听过一些关于团队文化和企业文化的一些概念，并没有特别深刻的印象。尤其我读了《基业长青》这本书后，让我感受到对于一个企业而言，决定短期的是技巧，决定中期的是战略，决定长期的是文化。企业文化对一家公司来说真的很重要，同样团队文化对于一个团队来说也很重要，我在带团队之初也曾经忽视了团队文化的冲击。在带领这个团队之初，我私下找一些团队同学做1on1沟通，我发现这里面的问题还是比较严重的，很多人为了避免故障遭受惩罚，不敢去重构优化代码，把自己封闭到一个很小的圈子，也没有过多的追求和理想，以前也没有末位淘汰机制，大家觉得可以继续吃大锅饭。当时部门都是工作多年的老人，老的风气和习惯已经形成了很顽固的不良文化，工作情绪受到很大的影响。老的不良的文化包括：做事情没有积极性；永远不承认自己的错误，永远找借口推卸责任，永远都是别人的问题；不求有功但求无过；责任心差，对待工作自我要求低；对工作安排喜欢讨价还价；在一个不好的文化氛围下，优秀的员工会被排挤，团队没有向心力，也很难留住好的人才，员工流失率会非常高。我认为衡量一个团队文化氛围是否有吸引力，有一个很重要的指标，新员工的流失率：如果一个团队氛围非常好，新员工入职以后往往能够快速融入进来，流失率很低；如果团队氛围差，新员工入职以后比较茫然难以融入，往往会很快离职，流失率非常高，实际上留不住新员工远远比留不住老员工更可怕。接下来我希望给团队树立的文化是：坦诚，公开，透明；平等相处，消除等级感；工作气氛轻松，团队关系和谐；敢于担当，主动承担责任；成就他人，乐于分享。关于团队文化这个话题其实很泛，可以单独写一篇文章出来的。这里我主要基于团队文化以上几点，谈一下我的一些个人的看法。坦诚的力量首先，我觉得坦诚无论对于一个 TL 还是团队成员来说，坦诚也是一种价值观，对于一个团队的发展来说是非常重要的。作为一个 TL，带领一支团队，我觉得最重要的是 TL 本人必须做到坦诚的态度，只有对团队坦诚，才能和团队之间形成信任，只有和团队形成了信任，才能成为一支默契的团队。通用电气 CEO 杰克·韦尔奇说过：什么是信任？当一个领导真诚、坦率、言出必行的时候，信任就出现了，事情就是这么简单。为什么坦诚精神能行得通？很简单，因为坦诚有化繁为简的力量！坦诚的性格是管理者最基本的要求，只有管理者坦诚，才能获得团队的信任，作秀式的演讲和奖励并不能够真正获得团队的心，还是需要在工作中脚踏实地一点一滴去做好最平凡普通的事情。坦诚能够让你直面自身的缺陷，有针对性地改变自己，解决团队的问题，造就一个互相信任的团队氛围。我见过一个比较典型的案例，日常工作中主管对于下属不够坦诚，下属与主管的平时一些工作沟通中，下属做的不够好的地方，主管不及时进行沟通与辅导，结果最后KPI 考核被打了低绩效。换位思考一下，这个被打低绩效的人是我，我也会不服气，有问题你为啥不提前告诉我，让我提前去改正。对待下属要有勇气，敢于指出他们的问题，对于表现不好的员工要敢于批评和管理，例如为什么解雇你。这些谈话和冲突往往让人感到不舒服，我也承认每次谈低绩效是硬着头皮的，但是你必须有这样的勇气，坦诚不仅仅要对那些表现良好的人，还要对那些表现糟糕的人。苹果创始人乔布斯是一个对自己、对别人坦诚得可怕的人，坦诚的残酷，直面事情最真实的一面。的确坦诚的态度在很多时候会让别人感觉不舒服，乔布斯粗暴的坦诚态度也备受争议，但我觉得，如果你是一个结果导向的人，还是应该尽量坚持坦诚的态度，否则最终的结果可能远远偏离你的目标。允许你的下属challenge你其次，我再聊一下关于平等相处，消除等级感，这点我觉得最重要的让大家感受到你的亲和力，不是一个高高在上的领导。比如很多时候团队一些技术方案的决策不是你一个人来决定，有时候还是要善于倾听一下团队成员的意见，要允许团队成员challenge你。其实，国内外要求下属服从的企业文化很普遍，这不一定是坏事，特别是公司如果有想法的人太多，想法又无法统一起来，公司的整体战略呈现精神分裂状态，那基本上就离死不远了。所以管理层统一公司战略，一线员工强调使命必达。国内的外企格外强调下属的服从性，把这一点作为员工的基本职业素养来培训，常用来讲解的故事就是《把信送给加西亚》，强调上司安排一项工作以后，下属不允许谈任何条件，不允许challenge上司，必须无条件服从，克服一切困难也要完成工作任务，以解领导之忧。这种执行力让上司感觉很舒服，而且公司管理实施难度也比较低。多数管理者都喜欢比较听话的下属，认为顺从的下属更好用。心态上高人一等，不会放低心态倾听下属的意见，即使自己错了也不会承认错误，一方面害怕自己的权威被挑战，另外害怕向下属认错，觉得抹不开面子。我不是圣人，作为TL曾经也犯过一些错误，我也曾私下里和个别同学道过谦。放开心态，不需要过多的太在意别人的看法，这些我觉得都是无所谓的小事。从我个人自身的一些经历来看，其实一味地要求下属服从是有害的，要适当允许你的下属challenge你。如果一味地要求下属服从，不能进行任何反驳，长时间下来会导致团队的人缺乏思考，只是一味的按照 TL 的想法去执行，当下属内心并不认可工作本身，仅仅出于职业性完成工作，成绩最多是合格，很难达到卓越。同时会导致下属缺乏工作积极性主动性，容易养成下属逃避责任的习惯。相反我觉得作为 TL 一定要鼓励下属积极主动地思考，让下属能够自己设定成长目标，对工作拥有归属感和责任感；尽量给予下属更自由的空间，不要设置过多形式主义的约束；要允许下属去challenge你，参与你的决策，甚至质疑你的决策。用这种方式增加下属对工作的归属感，工作责任心更强，更积极主动，能够自我驱动。当你的决策错误的时候，下属可以帮你纠错，集体的智慧毕竟高于个人，俗话说“三个臭皮匠赛过诸葛亮”。owner 意识“Owner 意识”主要体现在两个层面：一是认真负责的态度，二是积极主动的精神。认真负责是工作的底线，积极主动是“Owner 意识”更高一级的要求。自私确实是人的天性，不是自己的东西，很难谈什么责任感，更不用说主动性了。因此，团队管理就是要努力地培养大家的责任感，主人翁意识，想做到这一点，就需要增强团队成员的参与感，让他们知晓并理解所做事情的价值、来龙去脉，不断地强化使命感。例如可以将系统、业务范围等根据团队成员的兴趣点、以往项目经历等多种因素划分给指定人负责，并明确赏罚机制。要清晰地传达一种思想，那就是：这块东西就是你的，干好了评优、升职、加薪等都会优先考虑；干不好，出事情了，你要负责，我也会负责。如果有一天你看到团队成员像呵护自己的孩子一样，去对待自己的工作，那么你的目的已经达到了，他已经完全具备 owner 意识了。建立学习型的组织最后一点我要谈的是建立学习型的组织，团队成员要尽可能地分享自己的知识和想法，大家互相学习，也通过分享能够总结自己学习过程中零散的知识点。如何建立人才梯队的，其实就是要建立学习型组织，让大家积极参与学习与分享。具体做法KPI里设置一项技术分享与团队贡献，团队内部轮流进行技术分享，一方面让大家去学习、研究一些前沿技术，尤其是团队可能会用到的一些技术储备，如果他真的能把这个技术给大家讲明白的话，那他就是真的掌握了，同时也让其他人开始了解并学习这项技术，同时还能够锻炼其演讲与口才。鼓励团队成员敢于去分享，乐于去分享，开放心态成就他人。把技术培训和分享坚持下去，形成这样一种学习型的文化以后，你就会发现整个研发团队的技术能力的提升速度是非常惊人的，并且不会再占用太多额外的时间。当你再招一个资历较浅的新员工时，他也在能在这种环境中快速提升，通常半年左右时间就能达到非常好的水平。当然，一开始的团队可能没有这样的意识，就需要你作为管理者强行去推动，把要求列入KPI，很认真地考核他，慢慢地，团队就会形成这样的氛围和文化。当然建立这种学习型的组织，也可以建立一些读书分享会，把读的一些书籍感受分享给大家，另外一点团队的wiki知识库一定要建立起来，让团队同学把一些日常的技术方案、项目总结、故障总结通过文档的形势积累起来。沟通与辅导根据美国普林斯顿大学的调查报告，在所有对工作产生影响的因素中，沟通占的比例高达 75%。而我们工作中出现的80%问题都是由沟通不当造成的，可见沟通的重要性。多数时候，我们只想着表达自己的观点，只关注自己想说什么，我们会尽量使用漂亮的PPT、华美的语言、一堆的数据、甚至引章据典，而不关心别人听懂没有，没有思考别人是否想听，别人是否听得懂。沟通在我们的工作中无处不在，你会发现尤其在技术这个圈子里，能够进行高效沟通的人占比会更少一些。沟通按照沟通对象类型通常分为向下沟通(同下属沟通)、横向沟通(跨团队沟通)、向上沟通(同老板沟通)，接下来只讨论如何同下属进行沟通，最为有效沟通方式：一对一沟通。一对一沟通，又被称作一对一会议、One-on-one 等，是互联网公司常用的沟通方式。一对一沟通虽然被广泛使用，但是涉及的文章却很少，这里我给大家推荐本书《格鲁夫给经理人的第一课》、《创业维艰 : 如何完成比难更难的事》，这两本书有更多关于一对一沟通介绍。格鲁夫是 Intel 公司的总裁，成功带领 Intel 公司完成了从半导体存储器到微处理器的转型，也是我非常欣赏的一位CEO。《创业维艰》的作者本·霍洛维茨是硅谷的顶级VC，投资了Facebook、Twitter等公司。在《格鲁夫给经理人的第一课》一书中，格鲁夫对「一对一沟通」的介绍如下：在英特尔，一对一会议通常是由经理人召集他的部属召开的，这也是维系双方从属关系最主要的方法。一对一会议主要的目的在于互通信息以及彼此学习。经过对特定事项的讨论，上司可以将其技能以及经验传授给下属，并同时建议他切入问题的方式；而下属也能对工作中碰到的问题进行汇报。在我看来，技术研发同学多数比较内向，不轻易向别人表达自己内心的一些想法。一对一沟通的意义是可以使得信息从下而上地传递，同时可以把一些疑问、想法、意见、问题、规划等等和管理者做沟通，从而获得在其它渠道不易获得的信息，保证透明。1on1沟通聊什么在《创业维艰：如何完成比难更难的事》这本书中专门拿出了一节提到了一对一沟通（1on1），具体聊那些内容给了一些建议，作为TL我通常会与团队的人聊以下话题：你有没有认为自己的价值和能力被低估了吗？为什么？你觉得在工作中能学到东西吗？你最近学到了什么？你还希望在哪些领域进行学习？近期这段时间，对自己有哪些满意、不满意的地方？目前工作中，有哪些困惑？希望我如何去帮助你？对团队和我的一些期待和建议。在公司战略和目标方面，你最不清楚的是什么?以上这些内容，除了在一对一沟通中交流之外，很难找到别的渠道来有效解决。通过这些1on1的沟通，真的可以得到很多反馈信息，甚至得到的一些信息令我感到吃惊，原来还有这些细节问题我没有做好。一对一沟通构造了一个渠道，这个渠道自下而上，使得以上这些内容都能够被倾听，从而被解决。1on1沟通的一些注意点找个私密的环境找个空会议室或者别人听不到谈话的角落，不要在工位或嘈杂的环境中进行，因为私密的环境才能降低沟通中某些话被他人听到的心理压力，才能更轻松和真实的表达自己。最好提前告知1on1的团队成员一般需要提前1周把1on1沟通的话题、具体时间通知到团队成员，这样的好处是团队成员可以提前准备下聊的内容，因为临时性的沟通很容易出现因为人类记忆力的问题，导致一些想聊的问题在当时没想到。定期进行在《创业维艰》一书中，本·霍洛维茨认为一对一沟通需要保证至少一个月一次。而格鲁夫认为，需要根据部属对工作的熟悉度，而进行不同程度的掌控。另外，格鲁夫还认为，事情变化的速度也是影响一对一沟通频率的因素。作为技术研发部门，我通常会1-2月进行一次1on1沟通。用心倾听并行动沟通要有效，用心倾听、保持真诚是必要的前提，否则员工不可能将心中的问题提出来。保持真诚需要不敷衍任何团队同学提出的问题，不管这个问题有多尖锐。如果你也不知道如何解决这个问题，不妨和团队同学一起讨论讨论，看看大家能不能一起寻找可行的办法。切忌不要讲空话和套话，一旦团队同学发现这是一个无效的沟通渠道之后，「自下而上」的通道就被关闭了。适当引导并不是每一个员工都懂得一对一沟通的重要性，也不是每一个员工都能主动倾述问题，寻求帮助。很多程序员的性格都是比较内向的，有一些甚至不善于表达自己。所以，虽然员工是一对一沟通的「主角」，但是上司也是需要进行适当的引导。对于上司已经发现的员工工作中的困难，可以适当的主动提出来，以便于更好地讨论，这也会让员工感到很体贴。招聘与解雇对于一个团队来说，人才是最核心、关键的。招聘和解雇尤其对于一个新上任的技术TL，都是一个很大的挑战，接下来我们重点讨论这两个话题。招聘招聘很多时候取决于公司在什么发展时期，需要招聘什么样的人。在初创时期，本不太可能招聘到清一色的专家人才，这个时候活下来比啥都重要，态度和味道是重点看的。在高速发展之后，可能需要引进能带来新思路的一些人才，这取决于业务、技术、组织三者的对齐。那么这个时候，就是既要高技能，又要好的做事态度、习惯。在搭建技术团队招聘前，要先明确所搭团队的类型，一般来说有三种不同类型的技术团队，即项目驱动型、业务驱动型和技术驱动型，不同类型的技术团队在招聘时也有很大的不同，比如技术驱动型团队你可能需要一个在中间件、语言功底非常深厚、有大局观的人，业务驱动型的团队可能需要有业务sense，并且具备良好技术和业务架构能力的人。在招聘这条路上，我也走过弯路，一开始我对候选人的背景、语言功底、架构能力以及运维、数据库方面比较关注，希望能招到全栈的技术人才，后来发现我忽视了一个很重要的点沟通与协作能力、态度。后来导致新人来到团队后，虽然技术牛B，但喜欢闭门造车，不喜欢和别人沟通，团队协作能力不够好，整体产出和效率不高。所以在招聘新人的过程中，不能够只盯着候选人有什么经验，会什么框架等技术面，也需要着重考量他们的综合素质，一个领导力好的候选人，能够非常快速地融入团队，也能够非常快的学习一些知识。招聘步骤：1.根据搭建团队的目标，做好招聘计划根据团队自身的定位，招聘合适的人才。有几点需要TL特别关注的，作为TL要对候选人的成长负责，切忌因人设岗、因单独项目而招人，比如前端团队招聘一些后端开发，工程团队招聘算法，这样以来可能会导致候选人进来后很难融入到团队，没有存在感，长时间下来会导致新人离职。2.确定招聘需求（定岗定责）：列出每个岗位的职责、需要具备的技能及其他要求。招聘需求归根结底是需要什么样的人，与据整体业务和组织发展匹配。3.合理利用人才招聘渠道从我自身的经历来看，人才招聘渠道多数通过互联网招聘渠道以及朋友推荐更可靠一些，对于高级别的人才可以采用猎头定向挖人。人才筛选：作为技术面试官，对于人才的筛选也是非常重要关键的一个环节，要根据自己团队的目标来选取合适的人才，设定完成的时间期限，将面试的重点放在专业技能、管理能力、价值观（公司认同）等方面，一般要求如下：和岗位需要的专业技能高度匹配：专业技术技能面试过关，定岗定责；沟通力强：理解公司的业务，知晓管理层，了解公司的发展方向；责任心：凡事有交代，件件有着落，事事有回音；靠谱并自带正能量：不抱怨，主动解决问题，懂得纪律的重要性，一诺千金；价值观认同：认同公司，有目标有理想、有激情有冲劲；背景调查：非常有用的一个办法，可以大幅度降低选人风险，不用怕麻烦，这个工作的付出永远都是值得的。另外，我想说的对于技术面试官需要有一定甄别人才的能力，同时有意识地提高这方面的能力，我提供以下几点建议给技术面试官：如果对候选人有些犹豫和纠结，请你放弃这个候选人，你最担心的问题往往很大概率上会发生。明确我们招聘的候选人标准，比如后端JAVA研发：JAVA基础和分布式领域知识技能考察是必须的，少问记忆性问题和太理论性问题，更多地从候选人的一些实践经历中，提取出对这个候选人的更有价值的判断。一面非常重要，要保证客观、公平，后面的交叉和终面往往参考前面的评价反馈，我们今天不仅是为我们的团队选拔人才，更是为公司选拔人才，还是要高标准的要求。从心理学角度讲，必须要交叉面试，而且交叉面试官的给出的反馈往往是比较客观、中肯的，而且要以交叉面试官的评价为主。面试官切忌拿自己擅长的东西去考察候选人，需要认真的看候选人的简历，从候选人的经历中去考察这个人的综合能力。一个团队的健康发展，最重要的是核心技术人，所以招聘工作必须谨慎，一旦有人加入就等于在上了一艘船，其中的纠结、痛苦、欢喜都要一起面对。招募一个不合适人员的成本不仅仅是薪资那么简单。所以请一定要放过那些经验不错、资质不错但是很犹豫匹配度、落地融入堪忧的面试者，其结局大部分都是彼此痛苦。作为技术TL最成功的是招到比你更优秀的人，你不需要担心自己会不会被取代，一是成就个人和成就团队，作为TL应该抱着如何成就团队的发展思路，不能让自己成为天花板，本身技术就不应该是你最擅长的事情！二是兼容并蓄，发展多样性。刘邦善用汉初三杰，单项能力不如韩信、张良。TL不要已自己的长短来衡量招聘的人，而是看团队技能视图的缺口和发展项。解雇解雇员工通常更多的是针对触犯公司文化、原则红线，或者持续无法跟上公司节奏的员工进行的处理。在阿里也有这么一句土话：“如果你没有开除或解雇过一位员工，算不上真正合格的管理者”，大多数技术管理者性格比较随和，不喜欢开除员工。但是出现触犯红线的员工或者跟不上节奏的员工，尤其是不认可团队价值观的同学，会把一些负面情绪、行为影响到团队其他同学，因此需要杀伐决断，当机立断采用合适的方法让员工离开。当然，如果只是能力跟不上的员工，你也可以推荐给其他公司适合的岗位，让和自己一起奋战过的兄弟有一个好归宿，也会让在职的员工会感觉温暖。整体上“慈不掌兵”，在开人这件事情上，高级管理者不要过于犹豫，为了一两个人最后影响整体团队的士气反而得不偿失。多数互联网公司对于技术人员都有相应的KPI考核，对于达不到预期的人员会进行淘汰。解雇尤其对于新上任的技术主管还是有一定挑战的，我相信人的本性还是善良的，作为技术TL不想让团队成员面对这一难题，包括我自己在内。一家公司在成长，组织肯定要升级，人员的新老交替也是正常的。如果团队成员的表现达不到预期，不通过 KPI 考核机制告诉他，也许他不会意识到自身的一些问题，他永远不会成长起来，相对短期这些经济回报而言，个人的成长更为关键重要。在阿里有这么一句土话“不经历3.25的人生，不是完美的阿里之旅”，当你处于发展的低谷时，经历一次末位考核结果也许能够让他彻底清醒，认识到自己的不足，彻底激发自己的潜能，能够触底反弹。心理学上有个著名的邓宁-克鲁格效应，又称达克效应。大意是，人很容易对自我产生认知偏差，最简单来说，就是会过于高估自己。达克效应的曲线图：上面的图片上反映出，大部分人其实都处于愚昧之巅。人能够成长为智者和大师要先从愚昧之巅，掉到绝望之谷，然后辛苦攀爬，积累知识和经验，成为智者和大师。有担当的管理者的一个重要责任，就是把下属从愚昧之巅推向绝望之谷，至于能否爬上开悟之坡，看个人造化。一个合格的技术TL必须要给团队成员塑造一个绝望山谷，同时还要让他看到一个开悟之坡，这样员工会不断突破自我。作为一个有担当的管理者，我们不应该是一个老好人的角色，也要有冷酷无情的一面，阿里也有一句土话“心要仁慈，刀要快”，当团队中出现一些达不到团队要求的人，管理者应该主动去拉他一把，如果多次尝试，最终达不到预期，应该请他离开。因为到了中途，再被残酷淘汰，无论对组织，还是对个人，损失都更大。本文作者： 云狄 阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

摘要： “做工程要有‘拧螺丝’的精神，其实在工作中，我们也做了很多‘拧螺丝’的事情，包括在搭建每一个架构、每一个系统的过程中。”“一台机器可能有无数颗螺丝，需要一个一个地拧，而且需要一圈一圈地拧，才能让系统间严丝合缝，顺利工作。代码的世界里，一个项目到底成功与否，也是取决于几个模型的关键特殊设置，就像拧螺丝一样。”蚂蚁金服CTO程立说道，“做工程就需要这种奋力的精神。”近日，蚂蚁金服CTO程立接受了科技媒体infoQ专访，过程中，程立谈到了过去十年中国互联网技术的发展，与此同时，作为架构师出身，程立也谈到了做工程的心得。程立表示，“做工程要有‘拧螺丝’的精神，其实在工作中，我们也做了很多‘拧螺丝’的事情，包括在搭建每一个架构、每一个系统的过程中。”比如，程立回忆说，在十年的“双11”大促中，蚂蚁金服技术团队护航支付宝，只在2012年出过一次“问题”。据介绍，那时问题就出在一个“螺丝”上——一个类似软件“保险丝”的设计，即某两个系统之间，可以想象有一根“线”作为连接。简单而言，当时技术团队设计，“保险丝”在压力过大时熔断，来保护后面的系统不会崩溃。而在开始的时候，支付交易出现了不稳定的情况。后来发现，其实是“保险丝”设定的容量不对，于是把“保险丝”换成“铜丝”，让它不要起到保险丝的作用，就顺利过去了。“可以看到，大促前我们做了非常多的准备，但成败就在于一个关键的环节。”针对一个问题咬住不放松的奋力，贯穿了支付宝技术的研发实践当中。比如，在2010年，整个支付宝技术团队的目标只有一个：将支付宝支付成功率提升到极致。程立介绍，在这个目标驱动下， 2010年，支付宝不仅实现了支付成功率的提升，还实现了现在每天都会使用——快捷支付的创新，让移动支付成为可能。这个过程中，既有技术浪潮下对云支付架构的升级，也有对无数技术细节的打磨。拧过无数颗螺丝，包括从2010年第三代技术架构调整后到今天，支付宝金融科技技术让移动支付、实时风控与新型信用等成为可能，并且让技术真正成为金融业务创新的驱动力，解决了过去难以解决的金融业务问题，如“310”小微企业贷款、实时反欺诈等等。脚踏实地是因为对未来有更深的期待。蚂蚁金服CTO程立表示，过去十年是信息技术、互联网技术从量变到质变的过程，我们用技术改变了每个人的生活，改变社会的经济，但是，真正的技术革命才刚刚开始。“中国对创新的拥抱，是技术发展的最好土壤。在这片孕育创新的土壤上，未来中国互联网依然可以领先世界，生长出来更多原创的技术创新，做更多事情。我们还可以预见，图灵奖得主真正在中国土壤上生长出现。”本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

根据我的2019年个人发展计划，要做一个自媒体，经过1个半月的精心准备，自媒体计划终于正式启动了，而这背后涵盖了大量的思考、策划、设计、准备和技术性的工作，伴随着自媒体的内容输出，我也把建设的过程记录下来…万事开头难，今天先写第一部分也是最重要的部分-打地基导读一、为什么要做自媒体 1、积累的分享 2、自媒体的进化 3、价值观的输出 4、一种商业模式 二、我要做怎样的自媒体 1、价值观的思考 2、我的参照模板 三、我准备怎样来做自媒体 1、承认缺陷，不碰视频与直播 2、全平台主次分发策略 3、技术驱动的思路 4、佛系运营理念一、为什么要做自媒体1、积累的分享 在过去10年工作、创业的社会实践过程中，积累了大量的经验、案例与思考，我想把其中有价值的部分整理出来，分享给有需要的人。 我的本职工作是软件应用架构设计和编码，在这个领域，也积累了相当数量的代码、资源、方案和思路，希望分享出来能帮助到广大的程序员。 每个人在人生的不同时候都会有不一样理解，把这些过程记录下来，是值得而有趣的。岁月前头转身回看，这些积累的分享一定会有独特的味道。2、自媒体的进化 在过去我也一直有撰写博客的习惯，但为何还是给自己定位了一个全新开始的自媒体身份。因为在我的理解下，自媒体和博主是完全不一样的。 在基础软硬件工具愈加发达，信息通道足够流畅、平台赋能越来越充分的情况下，个体价值较强的人，很容易脱颖而出，输出载体也不仅仅是传统文字，还包括富媒体文字、静态视频、动态直播等等，这些输出的过程更是涵盖策划、编导、拍摄、剪辑等多种方式和技巧，又进一步提升了原始内容的质量。 博客时代甚至纸媒时代，原创作者只需要关注内容质量，剩下的交给平台，而自媒体不仅要做内容输出，还要亲自操刀内容的运营，而运营领域的复杂和多变，又是更大的挑战，能获得更多的学习成长，这也是我向往的事情。 自媒体也可以是体量巨大的价值体，甚至比肩企业实体，这颠覆了很多传统的工作观和社会秩序，伴随着KOL概念的流行，某些自媒体更成为了驱动社会变革重要因素，这就是时代的力量，我也想迎合这样的发展，深入其中探个究竟，赶一赶自媒体这班车的晚集。3、价值观的输出 在我30岁的时候，对意识形态还有阶级斗阵的理解又达到了新的层次，眼看国外泛自由化泛滥，白左横行，一地绿毛，国内又娱乐至死，人口停滞，社会问题频发，民族即将陷入危机。甚至在技术领域也政治正确严重，看似各路技术开枝散叶大步向前，实则大量无知的自由小鬼大权在握搅的天翻地覆，这些其实就是长期价值输出的结果。有时候你会发现真理真的掌握在少数人手里，而我也想去做一些改变，这种改变，必须要学会主动输出价值，有时候这甚至是一场你死我活的斗争，需要勇往直前。 在当下，自媒体无疑是最合适我去做价值传递的载体，日常分享经验，积累粉丝。当你的价值体系能够逻辑自洽，获得越来越多的人认可的时候，那就会形成群播效应，步入快车道，价值传递进入良性循环。4、一种商业模式 自媒体也成为了一种新的商业模式，内容输出带来流量，流量通过广告联盟和定向广告获得收益，价值输出聚集粉丝，粉丝带来更大的商业想象空间，和拿稿费的纸媒作者不一样，自媒体已经具备了超越部分传统企业经营的商业能力。在具备内容输出能力的情况下，如果做自媒体比做企业经营更挣钱，那这种高效的模式何乐不为呢？二、我要做怎样的自媒体1、价值观的思考 在我日常的对其他自媒体的阅读中，会看到眼花缭乱的技巧和方法，也能窥见混乱、投机甚至作恶。我想，我不是圣人，也希望借力打力，也想用信息差换取资源，也会使用小技巧来吸引粉丝，但这其中的行为边界如何设定，道德底线在哪里，是需要慎重拿捏的，所以如果开始做自媒体，第一个要思考的就是价值观问题。 我会有怎样的价值观呢，我总结有如下几条：坚持原创内容的用心输出。不论是自有文字的撰写，还是第三方资源的整理发布，都坚持以原创心态用心制作，保证内容的高水准输出，不随意输出，不烂输出。对版权的尊重和保护。考虑到我所擅长的搜索领域能够贡献大量的冷门、独家资源，那就就涉及到了版权问题。综合权衡后，我还是决定去做这些资源的分享，但会做好正版购买提醒，也留好顺畅的侵权删除通道。保证内容的真实性和逻辑自洽。很多自媒体会通过夸大甚至臆想的方式来编造内容，虽然短期内吸引眼球，但从长远看，一定会逻辑无法自洽而降低品牌公信力，我想我不能这样做，内容的戏剧极限是根据实际案例恰当改编。多多参与社会话题的讨论。很多自媒体会公开表达自己不参与政治讨论的立场从而避雷，但我在理解的同时完全不认可这样的做法，在我看来，别说政经不分家，即使是娱乐，也无法和社会现实完全脱离干系，对事情思考的深度也取决于对社会的认知程度。我想我愿意冒一定风险，聪明的在合理范围内，也尽可能的多多思考社会问题并发表见解，承担自己的社会责任。想方设法赚钱自循环。在微博观察众多大V很久后，我有一个思考，自媒体的立场深度，取决于自己生活的富足程度，越是有额外收益自给自足，越是能公开的、站着的通过自媒体赚取收益，那就越能够清晰无忧的表达立场和观点。所以赚钱这一观念，会融入我的整个自媒体建设过程，包括广告、广告联盟、打赏、合作、电商等，都是会尝试方向，至于赚钱的价值边界，我觉得只要认为自己是站着的就行了。2、我的参照模板 虽说我的偶像有限，但在自媒体领域，还真有一个特别佩服、特别喜欢的，微博名叫《股社区》，公众号名叫《招财大牛猫》，证券行业的优秀自媒体，我以为，不论是在文字功底上，领域专业性上，还是在自媒体运营方法上，他都做的非常出色而又与众不同，更难得的是三观健康，在不胡编乱造的情况下每日一篇依然输出质量极高。完美的诠释了什么叫一边在自己喜欢的专业领域慷慨分享，一边顺带着把钱给挣了（保守估计每日仅打赏数额在3-5万）。 我的自我剖析和他很像，在我的业务领域，除了文字功底稍差一些（写文章慢），深广度储备和输出能力甚至更佳，我想他是我在自媒体上努力的方向，也希望能有所超越，做一个独特的优秀自媒体。三、我准备怎样来做自媒体 终于到了关键环节，下面我把最近1个多月来对于如何做的思考和已经开展的工作详细介绍一下。1、承认缺陷，不碰视频与直播 虽然现在短视频很火，抖音、B站等视频平台机会很大，我也具备视频编辑能力，但我所输出的内容，包括经验案例分享、资源分享、技术分享等等，始终和视频不太靠边，而唯一可能的技术教程的视频或直播输出，也不是我感兴趣的领域。所以这个热点和红利，就战略性放弃了，只保持关注，不涉足其中。2、全平台主次分发策略 文字输出的平台很多，最重要的当然是微信公众号，除此以外，其他流量平台也不容小视，我比较自信自己的内容质量，所以定下了全平台分发策略，公众号首发外，其他平台均同步发布，从而争取更多的流量导入和发光机会。 目前选定的分发对象包括：大平台类：包括公众号、百家号、头条号、知乎专栏、微博头条、简书。技术平台类：包括博客园、CSDN、Github、SegmentFault、伯乐在线、开源中国、51CTO、云栖论坛。其他自媒体：寻找领域内适合投稿的优秀自媒体，主动投稿。3、技术驱动的思路 我是做软件架构的，这么多年的各类业务设计中，也一直坚持技术驱动的理念，这次也不例外，自媒体也可以技术驱动，具体来说，我有这些准备：++微信公众号技术化处理++。其中包括：1）托管微信订阅号，实现对自定义菜单、往来消息处理、关注取关用户等全面托管处理，并基于托管实现定向回复等高级功能。2）开发微信服务号，通过微信开放平台，做一个与订阅号相关联的服务号的托管储备，用于后续的高级会员管理、电商等功能拓展。这块的托管已经做好了，部分功能界面如下：使用Markdown格式的文字编辑。在跨平台传播上，MD无疑是非常优秀的，撰写简单，跨平台性好，便于存储，渲染时也能通过CSS二次定义样式。同时经过观察，虽然大部分平台支持MD格式，少部分还停留在传统的HTML编辑器，经过多方选型测试后，又引入了有道云笔记的桌面书写工具，具体策略为 1）在有道云中通过MD格式进行文章的本地撰写。 2）在支持MD格式的第三方平台复制MD代码直接发布。 3）在不支持MD格式的第三方平台复制有道云预览页面H5粘贴发布。 建设自己的图床。图片是文章发布不可缺少的部分，有的第三方平台会限制使用自有图床，而也有平台支持第三方图床，考虑到平台会进行图片审查，有失效风险，所以本地版本的文章内容，决定自建图床，我的建设策略为，阿里云OSS存储+阿里云CDN访问+本地小工具上传，阿里云的两个云产品的配合策略，可以到我的博客园找一下历史文章，有过详细介绍，而本地小工具也很简单那，上传+生成MD格式地址，如下图：做好发布登记。平台多了以后，哪个发布了哪个还没发布，一定要做好准确记录，后期计划纳入系统中进行精细化管理，当前使用Excel表格临时代替。技术性涨粉。考虑到订阅号已经托管，而我在资源搜集上又有独到的信息源和搜索能力，所以从技术上设计了一个涨粉的闭环逻辑，具体策略如下： 1）在管理后台做一个完整的资源信息管理。 2）每次在管理后台新建资源后，将实际的资源文件打包上传百度云、腾讯云等云服务平台，获得分享的下载地址更新到资源信息中，并在管理后台下载分享图片。 3）新建一个文章，用于详细的介绍这个资源内容，加入资源分享图片，发布到微信订阅号，并将文章详细介绍地址更新到资源信息中。 4）在其他平台发布资源文章或者资源下载信息。 5）需要资源的用户看到分享图片的文字描述后，关注订阅号，回复通关密码，获得最终下载地址。 到这里为止，完整的获粉逻辑就结束了，管理逻辑较为复杂，但对用户来说，是平稳顺畅的。4、佛系运营理念 内容输出后，就需要进行运营，我的运营思路相对简单，初期只有两点，简称佛系运营。坚持内容质量驱动。我始终相信自媒体只要内容好，质量高，就不缺听众和传播，机会和成长会主动找上门来，除了适度的使用一些图文技巧、标题文字技巧外，所以我会把大部分时间花在核心内容构建上，剩下的扩散机会就随遇而安了。适当的分发和投稿。当然了，我也会做一些适度的分发，主要包括在朋友圈、自己熟悉的微信群里传播，以及向领域内合适的其他媒体、自媒体投稿。好了，所有基础准备工作就是以上这些啦，做自媒体，我是认真的下面放两个已经输出的内容，有兴趣的可以看一看我的十年创业路ERP不规范，同事两行泪

“我是一位没上过大学的科学家”，谢崇进在公益课堂上说。讲台下，是450位将要面临高考的乡村学生。不久前，阿里巴巴首席通信科学家谢崇进通过网络视频的方式开课，向广东省汕头市潮南区陇田镇田心中学的学生们分享了他的求学历程。谢崇进出生于安徽马鞍山的乡村，没有上过大学本科，却通过自学考取了北京邮电大学硕士，从而开启科学之路。从安徽到北京、瑞典、美国，他的求知之路遍及多地，曾在被誉为这个星球上最厉害的实验室——美国贝尔实验室工作13年，被评为贝尔实验室杰出研究员。现在，他带领的团队是目前阿里巴巴博士比例最高的团队，科研之余开设公益课堂，他说：我想让乡村的孩子们看到更大的世界。没上过大学本科的科学家，从安徽乡村到美国贝尔实验室“从乡村中学到美国，一直坚持着自学，从而获得今天的成就，谢老师的学习经历让我佩服不已，也同时激励我更加努力学习奋斗，成为为社会造福的人。” 谢崇进的求学故事让田心中学G201班王如妹心中难以平静。这堂特殊的课，在他们心中播下了求知的种子。谢崇进小时候求学条件十分差，直到上初中时才第一次见到书店。“第一次去书店，很吃惊，书店里竟然会有这么多的书。”1985年，初中毕业的谢崇进没有选择上高中、考大学，而是考进了一所中专——山东邮电学校。当时，上中专除了能快点就业，还有着另一个重要的吸引力：可以从农村户口变成城市户口。谢崇进觉得，自己一生中的最大转变就是这次中专求学。在山东邮电学校，他选择了一个全新的专业——微波通讯专业。“我们老师说这是一个很新的专业，我也不知道是干嘛的，就是想学。”他说，“科研工作是什么？就是要探索未知，探索新的事物，发现问题并解决问题。”从微波通讯专业毕业后，谢崇进来到了安徽和县的一个微波站工作。微波站建在偏僻的大山上，他在这里工作了四年，一直利用业余时间自学。令所有人没想到的是，没有上过大学的他，竟然一举考取了北京邮电大学的硕士。彼时，拥有大学本科同等学历证明也可以参加研究生考试。这一次，走出大山的谢崇进沿着科学的道路，越走越远。1999年，在北京邮电大学博士毕业后，他来到了位于瑞典哥德堡的Chalmers技术大学从事博士后研究工作。2001年5月，他凭借优异的表现被美国朗讯公司贝尔实验室录取，成为这个被称为“星球上最伟大的实验室”中的一员。此后，他与光纤通讯研究结缘，从事光纤通信系统研究及网络技术的各个方面，成为光纤通讯领域的杰出科学家，曾经多次获得贝尔实验室主席奖、主席金奖，被评为贝尔实验室杰出研究员。“做科研工作，要对你的研究有充分的兴趣，同时要有好奇心，有想象力，和足够的耐心。”谢崇进对乡村学生们说，鼓励他们勇于畅想自己的未来。海外归国：加入阿里巴巴，推动光通讯行业技术变革加入贝尔实验室后，谢崇进发现，伴随着2000年左右美国电信泡沫破灭，通讯行业逐渐式微，与此同时，一个崭新的行业——互联网开始崛起，Google、微软、Facebook等互联网公司需求成为光通信技术关注的新焦点。谢崇进不知道的是，同一时期，远在大洋彼岸的中国，各大本土互联网公司也开始纷纷创立，崭露头角。2014年11月，已经蜚声海内外的阿里巴巴向谢崇进抛出了橄榄枝。他选择了加入阿里巴巴，成为阿里巴巴基础设施光通讯领域的奠基者。“阿里的平台足够大，对技术的投入也越来越多，假如你做一些技术的东西，通过阿里这个平台会放大，放大之后就会对行业产生一些效应。假如不在这个平台上，你的很多想法也产生不了这么多的影响，我觉得这还是蛮吸引人的。”伴随着中国社会经济的日新月异，阿里巴巴也保持着快速发展，谢崇进开始着手一些过去从未做过的事情，把实验室里的尖端研究落地成行业实际的应用。他感觉，在阿里巴巴，每年都会有一些新的东西在不断创新和变化，推动着他所从事的研究、应用已经进入到世界第一梯队。“我个人觉得，我们在光通讯这块在世界上可以排在第一梯队，有些方面比传统大厂做得还好一些，我能感觉到。”科学家这样做公益：让乡村孩子们看到更大的世界现在，谢崇进经常往返于杭州阿里巴巴总部和美国分公司之间，每一次，他都要回一次安徽老家。家乡正在发生着新的变化，如今乡村的孩子已经拥有了更好的学习条件，逛书店已不再是奢侈的向往。在阿里巴巴，马云对每位员工提出了“每人每年3小时公益”的倡议，让员工发挥自己的特长参与到公益中来。谢崇进选择了通过公益机构视频教学为乡村学生上课，他希望，通过自己的讲述，将希望带给更多的乡村学生。“有些学生并不是很了解外面的世界，给他们讲课，介绍自己的工作，可以增进他们对外界的认知。不过给这些学生讲课也不容易，要讲得深入浅出，还要生动有趣。”过去一年多，已经有40多位阿里巴巴员工成为公益课堂志愿者。除了科学家，他们中间还有工程师、律师、产品经理……通过公益组织途梦教育的在线视频，他们向云南、安徽、贵州、四川等地偏远地区的中学生分享自己的成长经历和职业故事，帮助学生拓展视野，丰富职业认知，并用真实的经历去鼓励学生们勇敢追梦。“能做这样的事情还是蛮有意思的，我还很想前往那些乡村学校，去看看这些孩子们。”谢崇进说。或许，若干年后，这些山村里的孩子能够怀揣着对科学和求知的热忱，走出深山，跨过大洋，在广阔世界中写下属于他们的故事。薪火相传，生生不息。本文作者：阿里技术阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

阿里妹导读：技术主管，又叫「技术经理」，英文一般是 Tech Leader ，简称 TL。随着工作经验的不断积累，能力的不断提升，每个人都有机会成为Team Leader。然而在机会到来前，我们必须提前做好准备，对TL的工作职责有一定了解。当然，这也会为当下更好地配合TL工作打下基础。今天，阿里巴巴高级技术专家云狄将结合自己多年的经验，从开发规范、开发流程、技术规划与管理三个角度出发，分享对技术TL这一角色的理解与思考，欢迎一起探讨交流。「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。接下来基于我在技术TL这个角色上，在开发规范、开发流程、技术管理与规划等方面我的一些心路历程，和大家共勉。开发规范我当时负责的业务是集团收购一家子公司的业务，在整体技术标规范上与集团的技术标准存在很大的差异。开发规范可以说是我来到这个团队干的第一件事，我当时面对的问题是API接口格式混乱，没有标准的RPC服务化，代码没有统一标准的开发规范，技术框架组件非标准化等一系列问题，作为一名业务上的新人，我第一时间制定了一套相对标准、全面的技术开发规范，边写代码边梳理开发规范，引领团队走向统一标准化开发道路。针对团队研发规范暴露的上述问题，主要制定了如下规范：命名规范我自己非常注重搭建项目结构的起步过程，应用命名规范、模块的划分、目录（包）的命名，我觉得非常重要，如果做的足够好，别人导入项目后可能只需要10分钟就可以大概了解系统结构。具体规范包括包命名、类的命名、接口命名、方法命名、变量命名、常量命名。统一IDE代码模板约定了IDEA/Eclipse IDE代码的统一模板，代码风格一定要统一，避免不同开发人员使用不同模板带来的差异化以及代码merge成本。使用IDEA的同学可以安装Eclipse Code Formatter插件，和Eclipse统一代码模板。Maven使用规范所有二方库、三方库的版本统一定义到parent pom里，这样来所有业务应用工程统一继承parent pom里所指定的二方库、三方库的版本，统一框架与工具的版本(Spring、Apache commons工具类、日志组件、JSON处理、数据库连接池等)，同时要求生产环境禁用SNAPSHOT版本。这样以来升级通用框架与工具的版本，只需要应用工程升级parent pom即可。代码Commit规范基于Angular Commit Message规范生成统一的ChangeLog，这样一来对于每次发布release tag非常清晰，Mac下都需要安装对应的插件，IDEA也有对应的插件，具体可以参考阮一峰老师的《Commit message 和 Change log 编写指南》。此刻忽然想起Linus面对pull request里的骚操作所发的飚：Get rid of it. And I don’t ever want to see that shit again. ——Linus代码的commit的规范对团队非常重要，清晰的commit信息生成的release tag，对于生产环境的故障回滚业非常关键，能够提供一些有价值的信息。统一API规范统一Rpc服务接口的返回值ResultDTO,具体代码如下：success代表接口处理响应结果成功还是失败，errorCode、errorMsg表示返回错误码和错误消息，module表示返回结果集，把ResultDTO定义到common-api顶层二方库，这样以来各个应用不需要来回转换返回结果。Http Rest接口规范约定同ResultDTO相差无几，需要额外关注一下加解密规范和签名规范、版本管理规范。异常处理规范异常处理不仅仅是狭义上遇到了Exception怎么去处理，还有各种业务逻辑遇到错误的时候我们怎么去处理。service服务层捕获的异常主要包括BusinessException(业务异常)、RetriableException (可重试异常) 到 common-api，定义一个公共异常拦截器，对业务异常、重试异常进行统一处理，对于可重试的异常调用的服务接口需要保证其幂等性。另外其他业务层有些特殊异常不需要拦截器统一处理，内部可以进行自我消化处理掉，根据场景对应的处理原则主要包括：直接返回抛出异常重试处理熔断处理降级处理这又涉及到了弹力设计的话题，我们的系统往往会对接各种依赖外部服务、Api，大部分服务都不会有SLA，即使有在大并发下我们也需要考虑外部服务不可用对自己的影响，会不会把自己拖死。我们总是希望：尽可能以小的代价通过尝试让业务可以完成；如果外部服务基本不可用，而我们又同步调用外部服务的话，我们需要进行自我保护直接熔断，否则在持续的并发的情况下自己就会垮了；如果外部服务特别重要，我们往往会考虑引入多个同类型的服务，根据价格、服务标准做路由，在出现问题的时候自动降级。推荐使用Netflix开源的hystrix容灾框架，主要解决当外部依赖出现故障时拖垮业务系统、甚至引起雪崩的问题。目前我团队也在使用，能够很好的解决异常熔断、超时熔断、基于并发数限流熔断的降级处理。分支开发规范早期的时候源码的版本管理基于 svn，后来逐步切换到 git，分支如何管理每一个公司（在Gitflow的基础上）都会略有不同。针对分支开发规范，指定如下标准：分支的定义（master、develop、release、hotfix、feature）分支命名规范checkout、merge request流程提测流程上线流程Hotfix流程虽然这个和代码质量和架构无关，按照这一套标准执行下来，能够给整个研发团队带领很大的便利：减少甚至杜绝代码管理导致的线上事故；提高开发和测试的工作效率，人多也乱；减少甚至杜绝代码管理导致的线上事故；方便运维处理发布和回滚；让项目的开发可以灵活适应多变的需求，多人协同开发。统一日志规范日志是产品必不可少的一个功能，具备可回溯性、能够抓取问题现场信息是其独一无二的优点，尤其在生产系统上问题定位等方面具有不可替代的作用。这里着重强调一下针对异常的日志规范：WARN和ERROR的选择需要好好考虑，WARN一般我倾向于记录可自恢复但值得关注的错误，ERROR代表了不能自己恢复的错误。对于业务处理遇到问题用ERROR不合理，对于catch到了异常也不是全用ERROR。记录哪些信息，最好打印一定的上下文（链路TraceId、用户Id、订单Id、外部传来的关键数据）而不仅仅是打印线程栈。记录了上下问信息，是否要考虑日志脱敏问题？可以在框架层面实现，比如自定义实现logback的ClassicConverter。正确合理的使用日志，能够指引开发人员快速查找错误、定位问题，因此约定了一套日志使用标准规范，现在可以更多的参考《阿里经济体开发规约——日志规约》。统一MYSQL开发规范表的设计和 Api 的定义类似，属于那种开头没有开好，以后改变需要花10x代价的，我知道，一开始在业务不明确的情况下，设计出良好的一步到位的表结构很困难，但是至少我们可以做的是有一个好的标准。统一工具与框架对开发过程中所用到的公共组件进行了统一抽象与封装，包括 dao 层框架mybatis、cache 组件 jetcache、httpclien t组件、common-tools (公共工具)，同时抽取出全局唯一ID、分布式锁、幂等等公共组件，把以上公共组件进行集成到各个应用，进行统一升级、维护，这样以来方便大家将更多的精力集中到业务开发上。开发流程目前团队的开发模式还是基于传统的瀑布开发模式，整体开发流程涉及需求评审、测试用例评审、技术架构评审、开发与测试、验收与上线，这里主要基于TL的角度从需求管理、技术架构评审、代码评审、发布计划评审几个关键重点环节进行探讨，欢迎拍砖。需求管理美国专门从事跟踪IT项目成功或失败的权威机构 Standish Group的CHAOS Reports 报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是"变更用户需求"。另外从历年的 Standish Group 报告分析看，导致项目失败的最重要原因与需求有关。Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目的变更。产品因需求而生，在产品的整个生命周期中，产品经理会收到来自各个方面的需求，但是每一个需求的必要性、重要性和实现成本都需要经过深思熟虑的分析和计划，避免盲目的决定需求或者变更需求，这样很容易导致工作混乱，技术TL如果不能正确的对需求进行把控，会导致整个项目偏离正确的轨道。需求管理的第一步就是要梳理不同来源的需求，主要包括从产品定位出发、外部用户反馈、竞争对手情况、市场变化以及内部运营人员、客服人员、开发人员的反馈。首先技术TL对产品有足够认知和把控，简单来说就是我的产品是为了满足哪些人的哪些需求而做，产品需求一定要根植于客户的需求、根植于客户的环境。每款产品必定有其核心价值，能够为客户创造更多的价值，基于此考虑往往能得到一些核心需求，摒除价值不大的需求。需求管理中最重要的就是对发散性需求的管理，往往因此也会导致产品在执行过程中不断的变更或增加需求。由于人的思维是发散性的，所以往往在产品构思的过程中会出现各种新鲜好玩的想法，这些想法可能来自领导或者产品经理自己，但是这些想法往往都是和产品核心方向不相关的，但是由于这些想法能够在当时带来诱惑，因此这些不相关的需求会严重干扰了技术团队的精力，打乱或者延误产品原本的计划。同样技术研发同学也需要建立对产品的深度思考，不要把自己定位成产品需求的实现者，同样需要对需求负责。很多时候需求的变更或增加是因为我们面临太多选择和想要的太多，没有适当的控制自己的欲望，并以自己的喜好来决定需求，这些因素很容易导致产品没有明确的方向、团队成员疲于奔命，但是却没有实际的成果。所以技术TL一定要能够评估出重新审视产品和筛选需求的优先级，识别每一个需求的必要性、重要性和实现成本。通过深思熟虑给团队明确方向并专注，聚焦资源的支配，确保团队的精力都聚焦在产品的核心需求上。技术架构评审互联网时代，大家提倡敏捷迭代，总嫌传统方式太重，流程复杂，影响效率，什么都希望短平快，在扁平化的组织中，经常是需求火速分发到一线研发，然后就靠个人折腾去了，其实技术架构评审这同样是一个非常重要的环节。架构评审或技术方案评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑，方案上线后是否会遇到不可逾越的重大技术问题，提前尽可能把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处。基于架构评审，我们的目标核心是要满足以下几点：1.设计把关，确保方案合格，各方面都考虑到了，避免缺陷和遗漏，不求方案多牛，至少不犯错。保证架构设计合理和基本一致，符合整体原则。维持对系统架构的全局认知，避免黑盒效应。通过评审发掘创新亮点，推广最佳实践。架构设计既要保证架构设计的合理性和可扩展性，又要避免过度设计。架构设计不仅仅是考虑功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，进行平衡和取舍。架构评审需要以下几点：技术选型：为什么选用A组件不选用B、C组件，A是开源的，开源协议是啥？基于什么语言开发的，出了问题我们自身是否能够维护？性能方面有没有压测过？这些所有问题作为技术选型我们都需要考虑清楚，才能做最终决定。高性能：产品对应的TPS、QPS和RT是多少？设计上会做到的TPS、QPS和RT是多少？而实际上我们整体随着数据量的增大系统性能会不会出现明显问题？随着业务量、数据量的上升，我们的系统的性能如何去进一步提高？系统哪个环节会是最大的瓶颈？是否有抗突发性能压力的能力，大概可以满足多少的TPS和QPS，怎么去做来实现高性能，这些问题都需要我们去思考。高可用：是否有单点的组件，非单点的组件如何做故障转移？是否考虑过多活的方案？是否有数据丢失的可能性？数据丢失如何恢复？出现系统宕机情况，对业务会造成哪些影响？有无其他补救方案？这些问题需要想清楚，有相应的解决方案。可扩展性：A和B的业务策略相差无几，后面会不会继续衍生出C的业务策略，随着业务的发展哪些环节可以做扩展，如何做扩展？架构设计上需要考虑到业务的可扩展性。可伸缩性：每个环节的服务是不是无状态的？是否都是可以快速横向扩展的？扩容需要怎么做手动还是自动？扩展后是否可以提高响应速度？这所有的问题都需要我们去思考清楚，并有对应的解决方案。弹性处理：消息重复消费、接口重复调用对应的服务是否保证幂等？是否考虑了服务降级？哪些业务支持降级？支持自动降级还是手工降级？是否考虑了服务的超时熔断、异常熔断、限流熔断？触发熔断后对客户的影响？服务是否做了隔离，单一服务故障是否影响全局？这些问题统统需要我们想清楚对应的解决方案，才会进一步保证架构设计的合理性。兼容性：上下游依赖是否梳理过，影响范围多大？怎么进行新老系统替换？新老系统能否来回切换？数据存储是否兼容老的数据处理？如果对你的上下游系统有影响，是否通知到上下游业务方？上下游依赖方进行升级的方案成本如何最小化？这些问题需要有完美的解决方案，稍有不慎会导致故障。安全性：是否彻底避免SQL注入和XSS？是否有数据泄露的可能性？是否做了风控策略？接口服务是否有防刷保护机制？数据、功能权限是否做了控制？小二后台系统是否做了日志审计？数据传输是否加密验签？应用代码中是否有明文的AK/SK、密码？这些安全细节问题需要我们统统考虑清楚，安全问题任何时候都不能轻视。可测性：测试环境和线上的差异多大？是否可以在线上做压测？线上压测怎么隔离测试数据？是否有测试白名单功能？是否支持部署多套隔离的测试环境？测试黑盒白盒工作量的比例是怎么样的？新的方案是否非常方便测试，在一定程度也需要考量。可运维性：系统是否有初始化或预热的环节？数据是否指数级别递增？业务数据是否需要定期归档处理？随着时间的推移如果压力保持不变的话系统需要怎么来巡检和维护？业务运维方面的设计也需要充分考虑到。监控与报警：对外部依赖的接口是否添加了监控与报警？应用层面系统内部是否有暴露了一些指标作监控和报警？系统层面使用的中间件和存储是否有监控报警？只有充分考虑到各个环节的监控、报警，任何问题会第一时间通知到研发，阻止故障进一步扩散。其实不同阶段的项目有不同的目标，我们不会在项目起步的时候做99.99%的可用性支持百万QPS的架构，高效完成项目的业务目标也是架构考虑的因素之一。而且随着项目的发展，随着公司中间件和容器的标准化，很多架构的工作被标准化替代，业务代码需要考虑架构方面伸缩性运维性等等的需求越来越少，慢慢的这些工作都能由架构和运维团队来接。一开始的时候我们可以花一点时间来考虑这些问题，但是不是所有的问题都需要有最终的方案。代码评审代码质量包括功能性代码质量和非功能性代码质量，功能质量大多通过测试能够去发现问题，非功能性代码质量用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低。代码质量应该更多的应该从可测性，可读性，可理解性，容变性等代码可维护性维度去衡量，其中 CodeReview 是保证代码质量非常重要的一个环节，建立良好的 CodeReview 规范与习惯，对于一个技术团队是一件非常重要核心的事情，没有 CodeReview 的团队没有未来。每次项目开发自测完成后，通常会组织该小组开发人员集体进行代码 review，代码 review 一般 review 代码质量以及规范方面的问题，另外需要关注的是每一行代码变更是否与本次需求相关，如果存在搭车发布或者代码重构优化，需要自行保证测试通过，否则不予发布。CodeReview 我会重点关注如下事情：确认代码功能：代码实现的功能满足产品需求，逻辑的严谨和合理性是最基本的要求。同时需要考虑适当的扩展性，在代码的可扩展性和过度设计做出权衡，不编写无用逻辑和一些与代码功能无关的附加代码。在真正需要某些功能的时候才去实现它，而不是你预见到它将会有用。 —— RonJeffries编码规范：以集团开发规约、静态代码规约为前提，是否遵守了编码规范，遵循了最佳实践。除了形式上的要求外，更重要的是命名规范。目标是提高代码的可读性，降低代码可维护性成本。潜在的BUG：可能在最坏情况下出现问题的代码，包括常见的线程安全、业务逻辑准确性、系统边界范围、参数校验，以及存在安全漏洞(业务鉴权、灰产可利用漏洞)的代码。。文档和注释：过少（缺少必要信息）、过多（没有信息量）、过时的文档或注释，总之文档和注释要与时俱进，与最新代码保持同步。其实很多时候个人觉得良好的变量、函数命名是最好的注释，好的代码胜过注释。重复代码：当一个项目在不断开发迭代、功能累加的过程中，重复代码的出现几乎是不可避免的，通常可以通过PMD工具进行检测。类型体系之外的重复代码处理通常可以封装到对应的Util类或者Helper类中，类体系之内的重复代码通常可以通过继承、模板模式等方法来解决。复杂度：代码结构太复杂（如圈复杂度高），难以理解、测试和维护。监控与报警：基于产品的需求逻辑，需要有些指标来证明业务是正常work的，如果发生异常需要有监控、报警指标通知研发人员处理，review业务需求对应的监控与报警指标也是Code Review的重点事项。测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖是否足够。实际上维护单元测试的成本不比开发成本低，这点团队目前做的的不到位。针对以上每次代码review所涉及到的经典案例会统一输出到文档里，大家可以共同学习避免编写出同样的Ugly Code。发布计划评审涉及到10人日以上的项目，必须有明确的发布计划，并组织项目成员统一参加项目发布计划review，发布计划主要包含如下几点：1）明确是否有外部依赖接口，如有请同步协调好业务方；2）发布前配置确认包括配置文件、数据库配置、中间件配置等各种配置，尤其各种环境下的差异化配置项；3）二方库发布顺序，是否有依赖；4）应用发布顺序；5）数据库是否有数据变更和订正，以及表结构调整；6）回滚计划，必须要有回滚计划，发布出现问题要有紧急回滚策略；7）生产环境回归测试重点Case。技术规划与管理我在带技术团队的这些年，对团队一直有一个要求，每周都要做系统健康度巡检，未雨绸缪、晴天修屋顶，避免在极端场景下某些隐藏的bug转变成了故障。系统健康度巡检为什么要把系统健康度巡检放到技术管理里，我觉得这是一个非常重要的环节。像传统的航空、电力、汽车行业都要有一定的巡检机制，保障设备系统正常运转，同样软件系统也同样需要巡检机制保障业务健康发展。随着业务的不断发展，业务量和数据量不断的上涨，系统架构的腐蚀是避免不了的，为了保障系统的健康度，需要不断的考虑对系统架构、性能进行优化。系统的监控与报警能够一定程度发现系统存在的问题，系统存在的一些隐患需要通过对系统的巡检去发现，如果优化不及时在极端情况会导致故障，巡检粒度建议每周巡检一次自己所负责的业务系统。系统巡检重点要关注如下几点：系统指标：系统CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。慢接口：通常rt大于3s的接口需要重点关注，极端并发场景下容易导致整个系统雪崩。慢查询：MYSQL慢查询需要重点关注，随着数据量上涨，需要对慢查询进行优化。错误日志：通过错误日志去发现系统隐藏的一些bug，避免这些bug被放大，甚至极端情况下会导致故障。技术规划技术规划通常由团队的TL负责，每个财年TL需要从大局的角度去思考每个季度的技术优化规划，去偿还技术债，技术债也是有利息的，因为利息的存在，技术债务不及时偿还的话，会在未来呈现出非线性增长，造成始料不及的损失。这里的技术规划包括如下几点：架构优化：一些结构不良、低内聚高耦合的代码则会使得哪怕是微小的需求变更或功能扩展都无从下手，修改的代价很可能超过了重写的代价。同样系统之间的耦合也需要重点去关注，遵循微服务化的原则，系统也要遵循单一职责原则，对于职责不清晰的系统去做解耦优化，进行一些模块化改造、服务隔离、公用服务抽象。性能优化：基于财年对于业务量、数据量的发展评估，根据目前系统服务的QPSRT,需要提前规划对系统性能进行一些升级策略，包括重点关注对一些慢接口、慢查询的优化。弹性与可靠性：系统提供的服务需要保障括数据一致性、幂等、防重攻击，同时也需要从熔断降级、异地多活的角度去考虑存在哪些问题，目前系统的SLA指标是否能够达到高可用，需要做哪些优化保障系统的高可用。可伸缩：应用服务是否保证无状态，关键节点发生故障能够快速转移、扩容，避免故障扩大化。总结大家不知道有没有类似的经历，某个时间段突然一些线上故障频发，各种技术债、业务债被业务方穷追猛打要求还债，如果出现这种现象很大程度这个TL已经失位了，这个团队失控了。也曾经有人跟我吐槽他的TL把活都分给他们，而TL自己什么都不干！这个技术TL真的什么都不干？曾经有一段时间我也在思考技术TL的核心职责到底是什么？技术TL应该具备哪些素质？首先技术说到底是为业务服务的，除非技术就是业务本身，必须体现它的商业价值。在很多公司里技术研发真的就成了实现其他部门需求的工具，我觉得这样的技术TL肯定是不合格的。首先它不能影响业务发展，需求提出方会经过很多转化，如果不是不假思索传递需求，整个过程会失真。第二个，我认为最最重要的是架构设计的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了技术TL这个级别，不能脱离一线太远，业务细节可以不清楚，大的方向必须要明确。如果没有很细腻的感知能力，很多的决策会有偏差。如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。关于技术层面，技术TL需要具备如下素养：技术视野良好，解决问题能力与架构设计能力出色。技术TL要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备。产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。动手能力要强，学习能力出色。技术TL并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作，技术TL不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。另外，技术TL也应该是一个学习能力非常出色的人，毕竟IT行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好技术TL的。技术TL除了管人和管事之外，其他还有很多事情要做包括建立团队研发文化、团队人才培养与建设、跨部门协调与沟通等，这样以要求技术TL也同时也需要具备良好的沟通和管理能力，以上观点仅是个人的一些思考和观点，仅供参考。本文作者：阿里技术 阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。 ...

阿里妹导读：新的一年，相信很多产品技术团队把研发效能提升列为重要的目标，甚至还有团队为此专门成立了项目组。然而，到底什么是好的研发效能，却很少有人能够表达清楚。标准不清晰，又何谈提升？今天，阿里研发效能部资深技术专家何勉老师，将与大家分享他多年的思考与观点，希望对你有所启发。本文将明确定义研发效能，并提供度量的五大指标，为研发效能的提升指明目标，并衡量提升的效果。本文也是关于研发效能提升及产品交付方法系列文章的开篇，为之后介绍的产品交付方法是否有效设立了标准。效率竖井是研发效能改进的最大问题产品交付需要前后职能（如：产品、开发、测试等）和平行部门（如：前端、后端、算法等）的协作。传统方法更多关注各个职能和部门的独立改进。然而，过度局部优化，往往导致效率竖井，反而损害整体效率。什么是效率竖井呢？上图描述了传统开发方式下，产品交付面临的普遍困境——各职能和部门局部优化带来一系列问题，如：基于局部信息的工作优先级安排，造成不同部门和职能间相互等待，让需求无法顺畅流动。比如前、中、后台对工作的优先处理不一致，进度无法对齐，让已经开始的需求不能及时交付。批量式的工作移交，带来进一步等待。为了最大化单个环节的效率，各职能往往倾向于批量接受和移交工作，如批量的集成，批量的转测等。进一步造成需求在过程中的积压和等待。跨部门的问题，经常得不到及时和有效的处理。公共环境的维护，就是一个典型的问题，是影响用户需求的顺畅交付。过程中需求跨部门的有效澄清、接口对齐、问题排查是另一些常见的公共问题，它们都会造成需求无法顺畅进展。以上只是一部分问题，它们共同作用，结果是：站在各自的视角，每个部门都觉得自己繁忙且“高效”；然而，站在全局和业务的视角，系统对外的反应却非常迟缓。这就是所谓效率竖井。效率竖井：由局部优化导致，表现为：各个环节和部门繁忙而“高效”，但总体的效率和响应速度却很低。它是研发效能提升的普遍症结所在。上图的折线反映了效率竖井下，单个需求的交付过程。绿色线表示需求正在被处理，红色线则表示需求在等待中。工作量不大的需求，交付周期却很长。因为大部分时间需求都处于等待状态。各个局部一片繁忙，外部却抱怨连连，相信很多人会感同身受。“持续快速交付价值的能力”是效能改进的核心目标要改进研发效能，我们必须走出效率竖井。为此组织必须把改进的焦点从关注各个资源环节，转向关注整个系统。上图反映了效能改进的关键——从以局部资源效率为核心，转变为价值流动效率为核心的改进。资源效率指的是，各环节的资源利用率和产出情况，如：资源的忙闲程度、使用率、代码产出和测试执行速度等。流动效率指的是，用户价值在系统中的流动速度，如：用户需求从提出到交付的时长，它越短越好；或者是过程中等待时间的占比，它越小越好。用户价值的流动是串起整个系统，促进整体优化的不二选择。为了提高价值的流动效率，组织就必须关注用户价值在系统中端到端的流动过程，改进整个系统，而不仅仅是局部环节。以此为基础，效能改进的目标是：持续快速交付价值的能力。这也是对研发效能的基本定义。持续快速交付价值的能力，是研发效能的核心定义。为此我们必须把改进的焦点从局部资源效率，转向价值流动效率，以保证全局和系统的优化。研发效能的度量——五组指标回答研发效能的根本问题以上定性的定义了研发效能。管理学之父德鲁克说：“如果你不能度量它，就无法改进它”。度量帮助我们更深刻认识研发效能，设定改进方向，并衡量改进效果。产品开发过程中会产生大量的数据，但数据不是度量。好的度量的标准是：它要为回答一个根本的问题讲述完整的故事。效能度量要回答的根本问题就是：一个组织“持续快速交付价值的能力”怎么样？为回答这个问题，应该提供怎样的一个完整故事呢？基于在天猫新零售、闲鱼、优酷、阿里健康、研发中台、阿里云等部门持续实践和探索，我们发展并验证了系统的研发效能指标体系。如上图所示，它由5组指标构成，分别是：第一：持续发布能力。具体包含两个细分指标，分别是：发布频率。 团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。发布前置时间（也被称为变更前置时间），也就是从代码提交到功能上线花费的时间，它体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。第二：需求响应周期。具体包含两个细分的指标，分别是：交付周期时间。指的是从确认用户提出的需求开始，到需求上线所经历的平均时长。它反映团队（包含业务、开发、运营等职能）对客户问题或业务机会的响应速度；开发周期时间。指的是从开发团队理解需求开始，到需求可以上线所经历的平均时长。它反映技术团队的响应能力。区分交付周期和开发周期，是为了解耦并明确问题，以做出针对性的改进。其中，交付周期是最终的目标和检验标准。第三：交付吞吐率。指的是单位时间内交付需求的数量。关于这一点，常见的问题是，个数能准确反映交付效率吗？这是个问题。所以，我们更多强调单个团队的需求吞吐率的前后对比，统计意义上它足以反映趋势和问题。第四：交付过程质量。它包含两个细分的指标，分别是：开发过程中缺陷的创建和修复时间分布。我们希望缺陷能够持续和及时地被发现，并且在发现后尽快修复；缺陷库存。我们希望在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。交付过程质量的核心是内建质量，也就是全过程和全时段的质量。而非依赖特定的阶段，如测试阶段；或特定的时段，如项目后期。内建质量是持续交付的基础，关于其具体度量方法，下文会给出详细实例。第五：对外交付质量。 它包含两个细分的指标，分别是：1)单位时间的故障（线上问题）数；2）故障平均解决时长。这两者共同决定了系统的可用性。如上图所示，这5组指标，从流动效率、资源效率和质量三个方面讲述了一个完整的故事，回答了组织持续交付价值的能力如何这个核心问题。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。一个度量指标实例：缺陷趋势图针对这些指标，云效提供了丰富的度量图表，后续云效产品团队还会进行场景化的梳理，提高其可用性。我会及时跟进，用专门的文章介绍云效的完整度量方案。在这里我先介绍一个例子——关于过程质量的度量图表。“缺陷趋势图”是云效新设计的度量图表，它反映交付过程中缺陷发现和移除的时间分布，以及缺陷的库存趋势。如上图所示，图形的横坐标是日期，横坐标上方红色竖条代表这一天发现缺陷数量；横坐标下方绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。缺陷趋势图是云效研发效能度量图表中的一个。后面，我会用专门的文章系统地解读这些图表的使用。效能改进的目标设定：部分团队的2-1-1愿景以上，我们介绍了研发效能度量。基于这样的度量体系，应该设定怎样的目标呢？我们在多个团队的实施过程中，逐渐沉淀出了可供参考的目标体系，它可以总结为三个数字——“2-1-1”。“2-1-1”最初来自天猫新零售，其后在闲鱼和研发中台、阿里云等团队完善和采用。什么是“2-1-1”呢？“2"指的2周的交付周期，85%以上的需求可以在2周内交付；第一个“1”指的是1周的开发周期，85%以上的需求可以在1周内开发完成；第二个“1”指的是1小时的发布前置时间 - -提交代码后可以在1小时内完成发布。[1]达成“2-1-1”的愿景并不容易。1小时的发布前置时间，需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升。1周的开发周期，涉及更多的能力和实践，如：需求的拆分和管理，开发团队的分工协作模式，以及持续集成和持续测试实践；最困难的则是2周的交付周期，首先它要以另外两个指标为基础，同时还涉及整个组织各职能和部门的协调一致和紧密协作；“2-1-1”的目标都是关于流动效率的，你可能会问，那资源效率和质量呢？我们专注于流动效率，是因为它是组织效能改进的抓手，能够触发深层次的和系统性的改进。就像上面分析的，为达成“2-1-1”目标，团队需要技术、管理、协作等方面的全面实践升级，而这些实践的落地，必然会带来资源效率和质量的提升，并体现到相应的度量指标上。当然，“2-1-1”是源自特定的团队，并非所有团队都要使用同样的值，比如对于涉及硬件开发的团队，两周的交付周期通常过于挑战。组织应根据自己的上下文设定恰当的目标，重要的是，它要指明改进的方向。总结本文定义了研发效能，它指的是一个组织持续快速交付价值的能力，可以从流动效率、资源效率和质量三个方面来衡量。其中流动效率是改进研发效能的核心抓手，它带来系统和全局的改进。如上图所示，研发效能最终为组织效能服务，必须体现到利润、增长、客户满意度等组织效能上；同时，研发效能的提升要落实到具体技术和管理的实践中，才可能发生。定义和度量是提升研发效能的基础，相信你更关心提升研发的具体实践和方法。后续，何勉老师将综合多个团队的实践，介绍可操作的实践体系和落地方法，还请持续关注“阿里技术”公众号，我们将尽快为你送上。本文作者：何勉阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

《JavaScript设计模式与开发实践》JavaScript版本的设计模式中，许多设计模式都可以用闭包和高阶函数来实现。使用闭包并不会导致内存泄漏，跟闭包和内存泄漏有关系的地方是，使用闭包的同时比较容易形成循环引用，这本身非闭包的问题，是浏览器的垃圾回收机制采取的是引用计数策略，只需要把循环引用中的变量设置为null即可解决。什么是高阶函数？至少满足下列条件之一者：①函数可以作为参数被传递 ②函数可以作为返回值输出AOP：面向切面编程的主要作用是把一些跟核心业务逻辑无关的功能抽离出来，这些跟业务逻辑无关的功能通常包括日志统计、安全控制、异常处理等。把这些功能抽离出来以后，再通过“动态织入”的方式掺入业务逻辑模块中。这样的好处首先是可以保持业务逻辑模块的纯净和高内聚性，其次是可以很方便地复用日志统计等功能模块。

《软技能——代码之外的生存指南》今天读的内容，章章命中要害，我正有这些问题，作者从一个过来人的角度给了自己的策略。第39章：超额完成工作第40章：对自己负责第41章：要不要多任务并行第42章：职业倦怠：我已找到解药我的定额工作法确保自己每天、每周都朝着自己最重要的目标取得明确的、可度量的进展。定额工作法还可以克服意志力薄弱的问题。（哈哈，比如我）什么样的工作时候用定额工作法？每周、甚至每天都会重复的不同任务，例如：每周写一篇博客、锻炼身体。为什么需要定额工作法？因为不能坚持不懈，不能按计划完成，总是觉得缺乏动力。比如：你制定了健身计划，但是发现自己去健身房的次数远远低于预期；开通了博客，想定时更新，但是几个月过去了毫无进展，你也清楚只要坚持更新博客，一定会看到非常好的效果，但是即便如此，你还是没有期望的那么多时间去写博客。定额工作法的规则：挑选一项重复性任务；明确有效时限，在此期间重复执行该任务；明确给定时间内任务该完成的次数；给自己承诺一定要达到定额；调整额度需要在下一阶段调整而非当前阶段。以缓慢稳定的节奏工作，要优于快速但缺乏持久和坚持的工作方式。（个人经历：这真是命中我的要害，我不知道从什么时候开始，我一旦短期看不到效果就放弃，怀疑自我，做事情没有坚持性。当我意识到这一点的时候是半年前，我开始调整自己的焦虑心态，倾向于慢慢去做，万事开头难，短期看不到效果的时候还是会急、会气馁，现在距离改正问题已经有半年时间，现在做事情的时候都会比较平和，尽管有时候还是身不由己想大跃进，但是已有效果，慢慢积累。）本着对自己负责的态度激励自己。如果缺乏对自己的责任感，你将永远依赖外部动机驱使你努力工作，你容易折服于一根胡萝卜的诱惑，也容易屈从与一根大棒的威胁。公开自己的日常活动也是一个好主意，如果缺少一周，一定会被发现。将自己的工作暴露在公众的监督下会有帮助，那种尴尬或者不想让自己新来的人失望的感觉会激励你采取行动。（比如我每天坚持写读书记录，既是温习一遍，也是定额工作、磨练意志力，自我激励）对于很多活动我们自认为是多任务并行，实际上不过是在不断地进行任务切换。任务切换越多，浪费的时间也越多，你的大脑并不能专注于一项任务。一次性完成一系列互相关联的任务。项目刚开始的时候，我们总是热情高涨、精力旺盛，但是一段时间之后，即便我们再有激情，一想到它们会让我们反胃，大多数人将这种状态称为倦怠。随着时间推移，成果进展缓慢消耗着你的动机，此时兴趣点也濒临低谷，你撞到了一堵你看不见的墙。解决的方法就是咬牙挺过去，经历痛苦就是克服倦怠的秘诀。坚持不懈成为高手是漫长单调的过程，你每穿越一次墙你将体验到全新的动力、充沛的活力，另外你的竞争者数量会越来越少。采取行动：想一想以前有哪些项目是你付出努力却没有最终完成而半途而废了，是什么原因让你放弃的？你现在对这事儿有什么感受？下次开始新项目的时候，下定决心：你一定会完成，或完全掌握。设定规则和约束条件，强迫自己穿过那堵不可避免的墙。如果你正面临职业生涯或者个人生活的一堵墙，试着去穿越它。想想在墙的另一侧会有怎样的收获等着你。想象自己的动机和兴趣终将获得回报。

《JavaScript设计模式与开发实践》昨天的总结中有几个不太准确，在这里重新总结一下。强类型语言、弱类型语言、解释型语言、编译型语言、动态语言、静态语言。强弱类型语言，系统是否对每一块内存有强制的定义，定义某一块内存在它声明的作用域内。动态语言和静态语言本质的区别是：是否允许运行期间对内存结构进行重分配、重定义。关于设计模式和语言的看法有些偏激，删掉了上一条记录的总结。第2章：this、call、applyJavaScript 的 this 总是指向一个对象，而具体指向哪个对象实在运行时基于函数的执行环境动态绑定的，而非函数被声明时的环境。this 的指向（1）作为对象的方法调用，this指向该对象（2）作为普通函数调用，this指向全局对象window（3）构造器调用（new一个对象），构造器里的this指向返回的对象。call、apply方法改变this的指向《软技能——代码之外的生存指南》不要努力成为一个成功的人，而要努力成为一个有价值的人。——爱因斯坦第22章：你的主要目标：为他人增加价值第23章：善于运用社交媒体如果你表达的和你传递的信息不能帮到其他人，那么每个人都将会无视你。人们最关心的还是自己。如果你能帮助足够多的人得到他们想要的东西，你就会得到自己想要的东西。要想给人们想要的东西，要先知道他们要什么。就像新娘在找心目中的完美婚纱时，只有切实看到了才会知道“这就是我想要的”。把你工作成果的90%都做成免费的。通过分享的内容和分享的方式塑造自己的形象。采取行动的思考：什么样的内容会让你觉得有价值？有没有哪个特别的博客会让你每周都去阅读，或者哪个播客的内容如此有价值让你欲罢不能？老刘的公众号和前端早读课的公众号可以说每天必看，老刘的知识星球氛围很好，比较活跃，常常有话题，感觉是一群人一起前进。阮一峰的博客浅显易懂，是快速入门的好工具，已经养成了习惯。

《软技能——代码之外的生存指南》我真的不是什么专家，我没有什么东西可以营销？即便你不认为自己是专家，也并不妨碍你现在就开始自我营销。事实上，试图找出自我营销的方法可以让你成为专家，专门从事某一特定领域的软件开发工作。基本上每一个开发人员都是有些能耐的——可能你观察事物的视角比较独特，或者可能你与其他软件开发人员的背景不尽相同，又或者你的兴趣爱好与客户或者其他软件开发人员相似。只要营销得法，即便是“菜鸟”或者“业余爱好者”的身份都是你的优势所在——很多人喜欢向比自己稍微优秀一点点的人学习，因为这些人是可望而又可及的。关键是，不要让“不是专家”成为放弃自我营销的借口。无论你身处自己职业生涯的哪个阶段，你都可以从营造和传播自己的品牌中获益匪浅。我真不知道该写些什么？许多想要开博客的人要么从来就没有开过，要么开了之后就很快放弃了，因为他们要么不知道该写什么，要么发现自己是在没什么可写。（哈哈，我也遇到了相同的问题，想起来自己荒废博客）解决这个问题的最好方法是提前头脑风暴出各种不同的想法，随时更新可能的博客主题清单，这样你总是保持一堆话题可供选择。（还有就是随着输入，就会多些思考，这也是话题的来源）同时，不要太担心你的文笔如何，不要太在意别人的想法。有时候你只要写一篇博客让自己的博客有内容，并不知道这篇博客会是自己点击量最高的文章，我写过不少自己觉得质量很差的文章，却成为最热门的文章。（我最开始写博客的时候非常担心自己的文笔，也很在意别人的想法，读过《原则》之后我的思维发生了一些转变，承认自己的缺点，并采取行动，比如我很懒，以前麻痹自己，导致很拖延，现在承认这个问题，然后积极采取行动，我现在变得不拖延了，如果你也有此问题，或许《原则》这本书可以帮你。）要想弄清楚写什么，还有一个技巧，就是与别人就某个话题展开对话、甚至辩论。我经常发现自己写得好的文章一般是先前与比人讨论过的。自我营销：你的营销手段决定了你营销对象是受益还是受损，优秀的营销会将人们的需要或者期待与能够满足此愿望的产品或服务关联起来，所以，营销追求的是“实现价值在先，要求回报在后。”“自我营销”就是把希望得到你提供的产品或者服务的人和你自己联系起来。自我营销的正确方式就是为他人提供价值。品牌是对产品或者服务的一整套预期。品牌的关键是品牌带给你的感受，是你与品牌互动时的预期。品牌即承诺：承诺按照你预期的方式交付你所预期的价值。这里我想到了我买衣服总去的几家店，拉夏贝尔、ONLY、ELAND等，来到这几家店我知道我一定会买到适合我这个年龄、工作环境、质量又好的衣服，我与品牌之间产生了互动，品牌给了我预期。品牌四要素——品牌所要传递的信息、品牌的视觉符号、品牌的一致性和品牌的曝光率。个人品牌一致性越强，就越能被更多的人关注，也更容易被记住。博客可以提高你的沟通技巧，组织自己的思想，并将其转化成为文字，是一项颇具难度却也极具价值的技能。定期写作能帮助你打磨此技能，有了很好的沟通能力会让你在生活的颇多领域受益。如果你能约束自己定期更新博客，你也就是在持续刷新自己的技能，保证自己处于自己所在专业领域的前沿。打造成功博客的最大秘诀有且只有一个——持之以恒地输出高品质的内容。这让我想起了《原则》书中，作者坚持很多年，更新自己在经济看法的每日一文，在《软技能》这本书中又看到了类似的观点，驱使我自己去实践这个行动，我尝试坚持去写每日阅读记，打磨自己的心性和能力。《JavaScript设计模式与开发实践》面向对象的JavaScript：语言特性静态语言：在编译时就已确定变量的类型。优点：编译时能够发现类型不匹配的错误，程序明确规定了数据类型，编译器还可以针对这些信息对程序进行一些优化工作，提高执行速度。缺点：迫使程序员依照强契约编写程序，在编写程序到时候，这些细节或让程序员的精力从思考业务逻辑分散开来，毕竟大部分写程序的目的是为了完成需求交付生产。动态语言：程序运行时，待变量被赋值以后才会具有某种类型。优点：程序员把更多精力放在业务逻辑上，专注于逻辑表达。缺点：无法保证变量类型，运行时可能发生跟类型相关的错误。作者这里用了一个很生动的比喻，好像是在商店买了一包牛肉辣条，但是真的吃到嘴里才知道不是牛肉味。鸭子类型： 通俗解释，如果它走起路来像鸭子，叫起来也是鸭子，那么它就是鸭子。（哈哈，很抽象）动态语言能够很轻松的实现一个原则：面向接口编程，而不是面向实现编程。比如：有push和pop方法，就可以当做栈来使用；一个对象如果有length属性，也可以依照下标存取，这个对象可以被当做数组使用。多态：通俗解释，给不同对象发送同一消息的时候，这些对象会根据这个消息分别给出不同的反馈。多态最根本的作用是通过把过程化的条件分支语句转化为对象的多态性，从而消除这些条件分支语句。（多么精辟）将行为分布在各个对象中，并让这些对象各自负责自己的行为，这正是面向对象设计的优点。原型模式不单是一种设计模式，也被称为编程泛型。基于原型的继承：var A = function(){}A.prototype = objvar a = new A()设计模式是对语言不足的补充，如果要使用设计模式，不如去找一门更好的语言。

今天阿里巴巴技术脱贫大会举行。说起这个大会，就要提起1年前投入100亿元人民币成立的阿里巴巴脱贫基金了。从教育到健康，再到女性、生态和电商扶贫，这五个方向分别由五位阿里合伙人直接牵头。许多人不知道的是，过去一年，数百位阿里工程师和产品经理在乡村呆的时间比在杭州的时间还要多，他们的办公地点分别在四川宜宾的猪场、陕西阎良的瓜田、四川平武的蜂场、云南的梯田……他们的足迹，遍布中国上百个贫困县。有人还因此获得了公司“空中飞人”奖。很多人也许看到了阿里脱贫基金的百亿投入，但这背后，还有看不到的工程师“脱贫代码”。今天，就和你说4个小故事。我们不是什么超级英雄，我们只知道，既然来了就必须做出点东西雷宗雄 阿里云技术小二我在北邮读的计算机专业，很早接触互联网技术和AI算法，当时的梦想是像马斯克一样能干点“牛到天上”的事儿。2014年毕业进入阿里，参与机器学习算法平台PAI的研发，在亲戚朋友眼里也算是“高大上”。但谁也想不到后面我会和猪发生联系，而且一干就是一年。去年年初，阿里云同四川特驱集团、德康集团合作，准备将ET农业大脑跨界推广到养猪场，选了20名工程师，我是其中之一。第一次出发去猪场前，总架构师慷慨激昂的说：同学们，中国的养猪产业将因为我们而改变。但到了猪场，发现根本不是那么回事。要个WIFI，没有；要环控设备接口，没有；要安装个智能传感设备，拉电线、组网络、调试系统都得从零开始。站在猪舍，有一种很绝望的感觉，只听见猪撞栏的声音、风机转动的声音、打料的声音……我和总架构师在宿舍大吵了一架：“你的规划就是扯淡，不可能实现的，完蛋了！”吵完呢，又继续干活。大家都很清楚，既然来了，就必须做出点东西。猪场的厂长挺积极，非常支持我们。因为现在95后已经很少有人愿意来猪场工作了，进了猪场就得被关一个月，地方又偏远。他就盼着机器人来帮他。在猪场，我们想了很多方案。比如行走机器人，让机器人在过道里不断走动，完成巡检、清扫卫生、加料等工作，彻底取代人。很性感对吧？但实验了几个方案之后发现，行走机器人根本迈不过横亘在它面前的猪粪。机器人倒在猪粪面前之后，我们决定用无人机。无人机定时在猪场内起飞、巡逻，完成对每个猪只情况的盘点、记录。但伸手就能摸到的房顶和凌乱的水线，又把无人机拦了下来。最后受盒马外卖传输索道的启发，我们在猪场顶部搭建了一个跑在滑轨上的自动巡查系统，完全DIY自己爬猪栏装上去的。在这里，猪脸识别等这些时髦技术完全没用，都是吹牛，能落地才是好技术。我们这套系统能够实现对每个猪只信息的几乎100%的准确判断，记录它一天的饮食、运动、饮水、精神状态、体型、产仔、断奶等数据，也成为后续各类算法的基础。从天马行空到有脚踏实地计划，我在猪圈待了整整三个月。现在，我们已经做了7套算法，另外几个课题还在研究。在技术落地方面，除了大型猪场，我们的技术也通过钉钉开放给了合作的家庭农场，这其中不少是贫困家庭。对于普通农户，以前由于技术和资金问题，养猪顶多养个十头。现在他们跟猪场合作，每家农户一年可以养500-1000头，在没有疫情损失下可以拿到9-18w不等收入，农户前期投入一般地在3年内能收回成本。有一次走访，一个养户因为一头猪死了，郁闷自责得快要掉眼泪了。我看了猪的死亡报告，完全就是因为着凉了没有及时诊断，最后不断的恶化，恶化到最后绝食厌食免疫力下降，一下子就摔倒了，摔死了。这些其实是有可能通过我们的技术提前发现的。我觉得，如果要想真正帮助传统行业、帮助农户，必须弯下腰跳进猪圈、走进牛棚、去到田间才行。我经常跟同事开玩笑，我现在养猪的技术差不多相当于本科毕业在猪场工作两年的水平。我们不是什么超级英雄，只是一群用代码改变传统养猪方式的“猪猪侠”。一年里频繁下瓜田，我得了个“空中飞人奖”熊琴 阿里云产品小二 我妈以前总说我，嘴这么会吃咋不会做呢？别说做了，我连什么菜什么瓜都分不清。没想到组建农业智能团队，给了我和瓜果蔬菜亲密接触的机会。2018年初我们开启“西安模式”，希望同西安六个县合作摸索出农业数字化转型方案，从此各种基地大棚，成了我和小伙伴的办公地点。西安阎良县是我们的第一站。当地标志作物是甜瓜，无论在口感上还是耐运输上，都具备了走出去的实力。但在让瓜走出去之前，如何走进农户们还真的考验我们实力。大棚里基本都是四十度，湿度大，日照强烈，每次下地都像在公费蒸桑拿。更要命的是，虽然是政府牵线的合作，但让种了一辈子的瓜农，相信我们几个没下过地的年轻人能改变种瓜模式，太难了！你能想到的解数，我们差不多都用上了。比如穷追不舍，跟着瓜农社长去勘测大棚，量间隔数、瓜架行数，细到每一株瓜苗上的花朵数。让社长看到我们是带着互联网数据思维和技术，决心要帮他解决管理痛点的。我们还找来农户们写的农事记录本，花了一个多月人肉整理。天书一样的笔记，信息化后大家都能看得懂了。还有算法博士认亲归宗的、拜把子认了俩兄弟的，追着别人认瓜苗，学习甜瓜的不同生长阶段、种植过程。等和农户熟了我们就开始跟他们“抬杠”，凭什么你说自己的瓜就最好，你的瓜到底有多甜，你知道买瓜的人怎么评价吗，证明给我们看看。最终，瓜农社长从“烦我们耽误工作”，到“我都听你们的”。他种了三十多年甜瓜，他太清楚农户们有多固执，也太希望有人来帮助他带领大家把瓜种好脱贫。像社长三十多年来的种瓜经验，我们也做成智能种植生产手册，大家通过手机就能查看。而每天包括天气、虫害等预警提醒，统一的种植任务，也能像发短信一样发给农户，按指示操作，种瓜可以变得傻瓜化。其实当初说要把数据智能技术应用到农业上，我们也不确定，因为传统农业太缺乏数据了。但现在随手一拍，农户就能参与到数据采集中来。而这些信息也是他们的资产，可以成为日后在蚂蚁金融产品贷款的信用信息。为了让甜瓜更能被消费者接受，我们为瓜设计了能溯源生产信息的身份证，还开发了扫描识别甜度的功能。从三月开始到秋季第一批甜瓜上线天猫，我因为频繁飞西安，飞回了一个“空中飞人”奖，从啥都分不清变成了蔬果带货达人，朋友总让我推荐什么好吃什么该买。希望我们的技术方案能把行业上好的经验、知识传播下去，让种植更科学高效，有钱可赚，年轻人愿意加入和留下来。而我更怕农户们急于短期收入靠打药增收，不仅种出的作物不安全对土地的破坏更是他们承受不起的。而信息化、数据化能帮助提高农业生产效率，市场的高标准能倒逼他们种出健康的产品，可持续发展才是我们用数据智能来做农业的根本。是好东西，我们就要让它好有所值姚义海 村淘运营小二 我是村淘的小二，我最擅长的是农产品种养殖。2015年底加入村淘后，不同品类都做过，到2017年，我开始做肉蛋禽相关的工作。不管是植物还是动物，发展农业，促进农品价值都是我最感兴趣的。来阿里之前，我自己做了几年农业创业，我爸就是老一辈搞种子研发的，我从小就对农业深有感情。所以我特别理解干农业的人怎么想？他们担心收成不好，害怕白辛苦换不来钱。2018年初，我们一大队人去到平武大山里，蚂蚁森林的同学在认真思考如何保护自然区，我们团队就在想，一定要挖掘出既不破坏环境、又能保证当地人收入稳定的产业模式。不然，保护环境容易但以山为家的当地人生活却困难了，保护也无法持久。当地有着百年历史的高山蜂蜜其实就很生态友好。但一大圈了解下来，我不得不说“祖辈传承”和“老手艺”这即是原生态，也是太原始。不过落后就意味着留给我们可做的事很多，让好蜜电商化走出深山这只是第一步，如何用技术优化整个高山蜂蜜产业让我更加兴奋。要知道养蜂这件事，对人要求并不太高，毕竟奔忙的是人家小蜜蜂。但平武人养蜂非常辛苦，难点在于这山太高了。平武山地海拔高，雨水多，山里容易滑坡泥石流。而很多公路只修到了山半高的地方，剩下一千多米的海拔只能人自己爬上去。我们有一次上山就遇到山石塌方，车动不了，路上全是山泥，每个人都是吊着一颗心摸爬上去。但蜂农几十箱蜂在高山上，心惦记啊，想一次就要爬一次，心累人也累。到了冬天，怕蜜蜂冻死，还必须把几十甚至上百个蜂箱背下山来，又危险又辛苦。怎么能让蜂农不那么费劲呢？我们自己也弄了一箱蜜蜂回来养，了解整个采蜜流程。我呢找业务相关从业者、内部算法的技术同学各种讨论，前后大概十来天，方案就出来了。大家直觉高山蜂蜜就该这么做。蜂农最关心的是蜂群的健康情况，于是我们在蜂箱口安上红外线探测，给蜜蜂计数。蜂农可以直接在手机上就看到自家的蜜蜂的活跃状况，发现异常再针对性上山查看。这样蜂农的精力就能大大节省。而采购端关心蜂蜜质量是否成熟，这也直接影响蜂农们的辛苦能不能换来回报。我们就继续在蜂箱上做手脚，安装GPS和重量监测，前者定位蜜源是不是高海拔山区，后者根据蜂箱质量变化和时间推算蜂蜜是否成熟。由于气候影响花期和蜜蜂的状态，我们的探测仪能记录天气、降水变化，未来还将通过大数据算法预测花期。蜂农根据手机提示就能科学管理蜂场，提前预测，让产量也能趋于稳定。我们把设备带回平武试点，当地蜂农说可算有人懂他们了，不用动不动往山上跑，蜜好能卖出去，这蜂没白养。以前当地人对养蜂很有感情，可往往无法靠这个生活。通过信息化新技术，现在他们有更多的精力养更多的蜂，而养多少都有渠道以比较好的价格卖出去，这下心态稳了。老蜂农感到轻松，年轻蜂农也没那么纠结，不再怀疑自己留在家乡养蜂能不能行。对我来说，蜂农们轻松了的感觉不仅重要而且意义深远。轻松了，就能真心真意做这一行，不再只是爱好而是职业。心里有底，对投入产出有明确预期，生活可期，年轻人也愿意留下加入高山养蜂，这才能让整个行业更好传承和发展。保护原生态很重要，但也要紧跟时代，我们正好去做这个桥梁。我觉得，用信息化技术解决他们的生产难处，靠电商帮助他们把蜜卖上好价格，其实是对当地人的尊重和肯定——既然是好东西，那我们就让它好有所值。世界很大，不要着急，值得妳们看看王菁 蚂蚁金服产品小二 朋友，“好保险”了解一下？别误会，我不是卖保险的。我是蚂蚁金服保险事业部的一名产品经理，“好保险”是我们针对贫困县女性开发的脱贫公益险。这个有点土的名字，却是我们好几个女同志想了好几天定下来的。它能让小姑娘上得起学，妈妈们生育能有保障，女子平安就是“好”呗。作为一个女宝妈，我看着贫困县里很多一脸稚嫩却背着娃娃的姑娘，明明是该上学的年级却在卤菜摊打工的小妹，非常心疼。所以，我们要做一个产品让女孩们面临选择时多一种可能。这个可能也许能改变她们的一生，晚了就真来不及了。因为我们都着急，不想等，所以使用我们的产品只要你准备好相关材料，最多72小时，理赔金就能打到你的卡里。有钱能继续上学，生病能去医治，就是改变贫困现状的转机，尤其对于在农村习惯自我牺牲的女性，能在需要帮助时获得支持，生活就能大不一样。在云南，我们遇到那个准备弃学打工的女孩蒲双双。其实她上职高是不需要学费的，但一学年一千块的学杂费家里也出不起。直到她弟弟都初中开学了，她才在老师劝说下拿回录取通知书，这时离高中开学已没两天了。我们教她用好保险，申请教育金，9月7日她已经重新回到学校了。做脱贫保险这两年，我真心体会到帮助得及时才能真的帮到他们。扶贫项目很多人做，但从募钱到用钱，没人说得清中间要多少时间、多少流程。很多时候是困难户真要帮助来申请了，一开始回复人家说有有有，结果拖很久最后却没有钱，大家心里落差很大。但现在，县里的扶贫干部跟我们说，村民们提交申请两天后钱就到账了，简直不可思议。为了他们这个“不可思议”，我们搭建了一个庞大而缜密的体系：支付宝提供前端平台、用户入口，蚂蚁提供区块链和AI技术支持，基金提供运营管理，保险公司提供推广网络，各级扶贫办牵线搭桥。对于当地人来说，只要全村有一个人的手机能安装支付宝，保险理赔就能顺利搞定。而对于捐助者，也能通过支付宝查看自己的钱去了哪里，帮助了谁。到目前，“好保险”已经试点了3个县覆盖16万用户，很多贫困家庭的女儿能因此继续念书。其实啊，我上大学的时候就很想做公益。但我心里也清楚公益不好做。现在，我的工作就是把公益技术化，用好产品把公益落地。这不仅实现了我大学的梦想，还多了一大帮有同样梦想的靠谱伙伴。我看着我们所做的事情，真的影响了很多人，尤其是那些山里的姑娘。我们用项目鼓励她们去读书我们就支持她们读书，希望她们不要急着打工别急着嫁人，这个世界很大，还有很多她们能去做的事情。女子就是“好”，我想我会把这些女孩的变化慢慢告诉我的女儿。四个故事都讲完了，有没有哪一个，在冬天里像阳光照进了你心里？他们只是扶贫背后无数阿里人的缩影。感谢每一个，为帮助他人而努力的努力。也希望，每一串看不见的代码，能给人带去看得见的美好而微小的改变！

2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践。蚂蚁数据库架构的三代升级史在过去的十多年时间里，蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代数据架构是构建在IOE的基础之上——IBM的小型机、Oracle的商业数据库，还有EMC的共享存储。基于第一代IOE架构的运维成本是非常高的，同时稳定性的挑战也是非常大的。随着业务的快速发展，这套架构已经完全没有办法适应业务发展的增速。随之诞生的是第二代架构，第二代架构的主体是OE——也就是Oracle和EMC，加上蚂蚁自身的分布式中间件，解决了业务的水平和垂直的弹性能力。这一代架构其实伴随着蚂蚁走了很多年。随着4G、5G时代的到来和金融的普及化，人们的生活越来越离不开移动支付，业务井喷式的发展给底层的数据库提出了更高的要求。这些要求包括更高的稳定性，快速恢复能力和极致的弹性能力等。于是最终演进到了我们如今的第三代架构。第三代架构是由OceanBase为代表的金融级云数据库和分布式中间件所构成。数据库架构升级的挑战伴随着整个蚂蚁的发展，整个数据库的架构也仅仅演进了三代。这其中一个很重要的原因就是对于任何企业而言，整个数据库的架构升级都是一件非常有挑战的事情。蚂蚁金服资深技术专家师文汇说道，“用一个我们内部经常说的比喻，就是数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。”更换引擎的目的是为了拥有更好的动力，做更多技术上的创新。但是横亘在眼前的问题是，如何才能做到稳妥创新，保证驾驶中的飞机平稳顺利的运行，这其实是有非常大的挑战。在过去三代架构的演进中我们可以看到，本质上每一代架构的迭代基本上都是以两到三年为周期，这其中会有非常高的人力投入和成本开销。第二个挑战就是从传统的商业数据库迁移到OceanBase数据库之上，我们如何保证迁移过程中以及迁移以后的稳定性。另外一个非常大的挑战就是数据质量，在金融企业里，数据承载的不仅只是钱，更承载了数以亿计用户的信任。所以数据一条不能丢，一条不能错，这是我们做数据库的底线。当然，包括兼容性问题和性能风险也给数据库的架构升级带来重重挑战。OceanBase迁移服务：向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案——OceanBase迁移服务（OceanBaseMigration Service，简称OMS）。OMS的发展演进OMS的演进是以业务为驱动，并且与OceanBase的架构升级和不断发展密不可分。早在2014-2015年期间，蚂蚁主站上的一些核心业务，包括大家熟知的交易业务，支付业务和会员业务等，需要从Oracle迁移到OceanBase上。当时的OMS还是以一个工具类、模块化的形态支撑着这些项目。所以在2015年我们开始对OMS的方案进行全面的调研，力求沉淀出通用的系统化的解决方案。在2016年，OMS已经有了平台化的架构，引入了大规模编排的思想，将整个迁移特别是切换过程中繁琐易错的环节全部集成到平台。这一时期，OceanBase也完成了从0.5版本到1.0版本的架构升级，这一年OMS还支撑了网商银行、印度PayTM以及主站的核心业务升级到OceanBase 1.0版本。到了2018年的时候，无论在基础功能层面还是任务编排层面，OMS都已经被打磨得日趋完善。今年OMS已经支持了蚂蚁森林，蚂蚁商户平台以及众多大量核心及非核心的业务从MySQL迁移到OceanBase之上。与此同时，在外部业务包括很多已经上线OceanBase的商业银行，也已经验证了使用OMS一键迁移到OceanBase的能力。OMS的方案优势OceanBase迁移服务其实主要解决了五个重要的问题。1.负载回放验证：其中第一个核心的问题就是负载回放验证，通过采集源端数据库的SQL流量，在目标库OceanBase上回放，可以验证其在OceanBase上的功能是否兼容、性能是否出现问题等。同时基于蚂蚁DBA十多年的经验沉淀，OMS会为客户提供性能等方面的调优建议。2.秒级数据校验：第二点就是数据校验，OMS有三层数据校验，可以做到秒级的延迟。举一个例子，比如说我们想把传统商业数据库替换成OceanBase，如果在迁移过程中任何一条数据出现了错误，在一秒钟内就可以快速发现。校验的延迟可以完全保证在一秒以内，根据蚂蚁线上的经验，大概在100-200毫秒之间。3.分钟级即时回滚：第三点也是最重要的一点，就是OMS有随时回滚的能力，而且回滚是无损的。这也是我们前面所强调的稳妥创新的基石。4.多种数据库类型支持：目前OMS支持源端数据库类型有Oracle、MySQL、OceanBase等等，支持全量迁移和增量数据同步。5.一键完成迁移：整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成，使用简便。OMS的技术架构OMS的核心方案其实非常简单，我们把OceanBase变成Oracle/MySQL的一个备库。传统的商业数据库一般都是有主库和备库的：主库承担写的流量，如果主库出现问题，我们会把数据切到备库，然后通过OMS提供的一整套虚拟主备库的解决方案完成切换。比如原来Oracle有一个主库一个备库，然后OceanBase其实变成了一个虚拟的备库。整个数据库架构的升级也会变得异常简单，简单到只是做了一个主备切换。回滚也会变得非常简单，其实也是做了一次主备切换。从OMS的整体架构来看，其实一个非常关键的点就是，我们在传统的商业数据库和OceanBase之间建立了一套虚拟的主备链路，整个OMS里用到的所有组件，其实都是在蚂蚁和阿里有很多年技术沉淀的，也都是基于真实场景所产生的。OMS的迁移流程OceanBase迁移服务的整体迁移流程其实只有七步。1.评估：首先第一步是通过负载回放工具做兼容性分析;2.PoC：接下来OceanBase云平台可以帮助客户部署一套PoC集群;3.预迁移：然后OMS把线上的Oracle的数据预迁移到一个测试库里；4.验证：在这个测试库里用负载回放工具去回放这些SQL，然后找到SQL里不兼容，性能或者数据质量不满足预期的部分，并提供优化建议；5.正式迁移：前四步做完了以后，业务需要调整或者需要优化的SQL已经完成优化，然后就可以正式迁移了。首先把原有的全量数据迁过来，然后再把增量变化的那部分数据实时同步过来；6.校验：等到所有的数据准备好以后，然后我们继续完成三级校验；7.切换和回滚：等到所有的校验都完成以后，可以一键完成切换和回滚功能。通过这七步就可以轻松完成从传统商业数据库到分布式数据库的完整迁移。蚂蚁商户平台基于OMS的业务实践蚂蚁商户平台承载着商户档案数据信息，订购关系、签约信息的数据和相应的服务能力。其中一部分业务使用的是MySQL数据库，还有一部分核心业务使用的是Oracle数据库。随着商户的快速增长以及业务场景的不断丰富，商户平台数据增长迅速，数据规模相当庞大。尤其是MySQL的单表瓶颈日益明显，DDL变更、DML更新的性能与风险已经无法承担。蚂蚁金服技术专家韩谷悦介绍道，“OceanBase能够支持数据的无限扩展，满足商户业务的容量与性能需求。那么如果我们换一种数据库底盘，其实所要面对的性能、稳定性和数据质量的风险同样不可避免。”从蚂蚁商户平台的业务实践来看，使用OMS迁移与传统迁移进行对比，我们可以看到：· 业务评估和改造过去通常一个业务少则花费1-2个月的时间去做改造和适配；那么基于OMS自动化的SQL兼容性评估和负载回放的能力，蚂蚁商务平台业务的改造大概只用了一个星期的时间。· 数据迁移和校验客观来讲，迁移的总时长主要取决于业务数据模型，数据量和网络环境。在提高迁移效率方面，OMS目前增量迁移的延迟仅为毫秒级，跨城情况下最长只需要3秒。并且针对校验出的数据差异提供补齐的SQL和订正方案，使得迁移和校验的整体效率有了大幅度的提升。· 业务切换其实在切换之前，往往需要制定严密的切流方案和Failover方案，整个切换过程中需要检查与校验的细节非常繁琐，任何一步疏忽都有可能造成数据不一致的问题。那么OMS通过引入大规模编排的思想，把所有繁琐复杂的环节通通落到平台当中。所以从原来业务切换需要用时1-2周时间， 使用OMS后蚂蚁商户平台业务无论是切读还是切写的过程中都只用了几分钟的时间。· 业务回滚在过去，迁移之后的业务回滚要担负重大的决策风险，OMS使得业务回滚就像一次主备切换，可以瞬间完成并且不丢数据，所以让业务回滚不再成为难题。商户业务整体迁移的过程中也发生过业务抖动，使用OMS回滚的时候从登陆系统到完成回滚也只用了几分钟的时间。所以全程下来蚂蚁商户平台这个业务的迁移时间大概在三个多星期的时间完成，那么无论从人力成本还是时间成本上，OMS都极大地提升了数据库的整体迁移效率。最后，韩谷悦为大家展示了OMS一键迁移的demo演示。当前， 越来越多的企业已经认识到分布式架构在实现业务灵活扩展以及敏捷开发等方面的巨大价值。OceanBase不断通过产品端的革新，为传统企业输送“互联网基因”，帮助更多客户向分布式架构转型。同时OceanBase也在不断提高服务客户的深度和广度。深度意味着在同样的业务场景下，随着业务的发展和体量的壮大，帮助更多企业承担起业务所带来的极致压力。广度则针对的是随着新型技术形态和业务场景的出现，帮助更多企业快速响应，通过技术创新而适应变化所带来的新的市场契机。OceanBase致力于将蚂蚁自身业务多年沉淀下来的最浓缩，最经典和最普世的方法论输出给广大的企业客户，同时做到深度和广度并存，真正帮助客户实现稳妥创新。

mPaaS是源于支付宝的移动开发平台，从最初的金融级移动开发平台，逐渐演进成集开发、测试、发布、分析、运营于一体的 App 全生命周期管理平台，服务了广发银行、12306、上海地铁等标杆级客户，帮助客户完成技术升级与业务增长。“拷贝”支付宝？呵，别逗了，这不可能。但支付宝工程师们真的把这种“不可能”变成了可能。1月4日，在上海举行的蚂蚁金服ATEC城市峰会上，新一代的移动开发平台mPaaS（mobile Platform-as-a-Service）3.0正式上线。新版本围绕移动场景完成了全面智能化升级，形成分析、营销、预测、多媒体等四大 AI 能力矩阵。此外，mPaaS 3.0版本提供了一套完备的H5/小程序应用开发、运维、分析功能，并提供底层小程序业务接口扩展能力，开发者可以利用mPaaS 小程序框架自主的开放业务接口。“新版本以智能技术助力客户构建自己的超级 App，并可以基于自有 App 做技术开放，构建超级 App生态，企业可以拥有等同于支付宝的能力，包括技术、生态、业务等”，蚂蚁金服金融科技产品技术总监杨冰介绍。mPaaS的演进之路正式介绍全新一代的mPaaS之前，我们先来回顾一下这个神奇平台的发展历程。2015年，金融行业风口已至。顺应趋势、助推行业整体进化，蚂蚁金服提出互联网助推器计划，发布蚂蚁金融云。支付宝从担保支付到国民App的过程中，沉淀了大量的技术实践。但如何将支付宝多年沉淀的技术在金融行业落地，这成了当时的一个挑战。2016年上半年，蚂蚁金服副CTO胡喜拍板，秉承“技术成熟一个，开放一个”的大原则，用轻量级的方式让蚂蚁的金融科技能力落地开花，因此首选mPaaS，并将其率先实施于蚂蚁的自有业务——网商银行，取得了非常有成效的结果。随后，mPaaS在信美保险和天弘基金也进行了落地。最开始的时候，mPaaS初期主要支持内部业务，所以并没有做多租户模式，而是采用的独占的模式，让用户去买机器，在公有云上，用户购买了服务后只能自己用。但支付宝工程师要以云的方式来完成这个动作，使其成为一个资源池。mPaaS的演进开始了。支付宝工程师最先做的是，先将mPaaS组件化、共享化，即用户可以自行挑选适合自己需求的组件，而无需整体采购全套方案。紧接着，mPaaS推出了一些热点的创新功能，比如热修复、离线包等。所以，在2016年11月的时候，mPaaS推出了一个更新的版本。如果说之前的mPaaS主要落地与支付宝内部的业务；那么此时的mPaaS已经具备了对外商业化的雏形，已经是一个正式的商业化版本。与此同时，mPaaS迎来了发展过程中一个非常重要的客户——12306。基于mPaaS的底盘技术，支付宝工程师对12306做了一个大的升级，并取得了非常明显的效果。新版12306 App无论是在流畅度，还是用户体验的方面，都取得了很好的反馈。为此，铁道部还专门给mPaaS团队发了感谢信，对支付宝团队的专业精神，还有技术深度都进行了高度的赞扬。12306项目的大获成功，不但解决了实际的痛点，也坚定了支付宝技术团队的做移动技术开放的决心。要知道，这个项目是10多个人的团队在不到2个月的时间内完成的，而且平稳顺利地经受住了当年的春运亿级用户的考验，是支付宝技术在相同体量 App 中的第一次成功复制。支付宝工程师们马不停蹄，立志要解决金融行业的痛点。此时，mPaaS的第一个金融客户广发银行出现了。彼时，广发银行研发中心总经理李怀根计划对旗下的App进行优化升级，其中最主要的是进行性能优化，即App的启动速度较慢，他希望立即将其解决。支付宝工程师用了一周左右的时间，设计了一个POC（Proof of Concept），就把广发银行App首页的代码“搬到”了mPaaS上，并在行里进行了现场对比 Demo, 对比发现精彩的平均启动速度从几秒缩短到不到1秒。最终广发银行在众多厂商中选择了与源于支付宝的 mPaaS 合作。新版发现精彩上线后，李怀根更在2018年云栖大会中总结到：“发现精彩 3.0 平均启动速度达到了0.52秒，iOS 闪退率不到万分之一，发现精彩整体体验大幅度提升！”这是mPaaS在高并发，大体量金融级 App 中的又一次复制。“拷贝”支付宝，新版mPaaS的魔法mPaaS是源于支付宝的移动开发平台，现在已经演进成集开发，测试，发布，分析，运营于一体的App全生命周期管理平台。1月4号发布的mPaaS 3.0 融入了人工智能小程序技术，进行了全面的升级。魔法一：全面升级的智能化能力mPaaS 3.0全面向智能化进行升级，推出了智能投放，舆情分析，多媒体，预测4款智能化组件。同时智能预测圈人的功能，与之前发布的消息推送服务（MPS），发布服务（MDS）进行了全面整合，例如可以通过智能预测来判断接下来一周即将流失的客户，然后针对这部分用户发布一个消息 （通过MPS服务），或者通过智能投放服务发放一个营销活动（通过智能投放服务MCDP），促使这些用户能够继续留存下来。所以这次升级不仅仅是推出了智能化组件，更是整个平台的智能化升级。同时 mPaaS 3.0 解决了智能化能力落地难的问题, mPaaS 提供数据采集，智能引擎，智能化场景一体化解决方案，开箱即用，无需做任何系统对接，数据对接。同时，也提供了数据和系统的扩展能力，可以结合业务数据服务更多的场景。魔法二：通过小程序构建自主的生态系统新版的mPaaS还提供mPaaS小程序功能，mPaaS小程序源于支付宝小程序，是支付宝小程序技术的全面开放，包含了小程序开发框架、IDE、发布服务、分析服务等完整能力闭环，让客户可以以小程序的方式开放业务接口，围绕自己的App构建小程序生态。同时，基于mPaaS小程序开发的业务可以在自有App、阿里系、mPaaS生态间投放、联通、共享，壮大客户自主的业务生态。魔法三：全新组件“真机云测”面向碎片化严重的安卓市场，新版的mPaaS还推出全新组件“真机云测”，帮助App在上线前完成全面、统一的测试方案，从而彻底验证App的兼容性、功能完善与性能稳定。 “真机云测”提供了包括机柜，测试框架，任务调度平台，测试效果评估一体化解决方案，可以有效的提高测试效率，降低测试成本，提高问题发现率。目前，mPaaS真机云测已在支付宝体系内完成 50w+自动化任务，用例执行400w余次，捕获闪退 5w+次。基于以上技术创新，新版的mPaaS让“拷贝”支付宝更加便捷。毫不夸张地说，通过蚂蚁金服的移动开发平台mPaaS，企业可以拥有等同于支付宝的能力，包括技术、生态、业务等。目前，全新一代的移动开发平台mPaaS已经在蚂蚁金服金融科技官网（https://tech.antfin.com/produ…）上对外开放。

2019年1月4日，以“数字金融新原力（The New Force of Digital Finance)”为主题的蚂蚁金服ATEC城市峰会在上海隆重举行。大会聚焦金融数字化转型，分享新技术的发展趋势与落地实践，议题覆盖金融智能、金融安全、金融分布式架构及数据库、财富管理创新等多个板块，助力长三角地区金融科技发展，引领数字化转型潮流。“蚂蚁金服十余年风控路，因为守护所以安心”。会上，蚂蚁金服大安全副总经理王黎强分享了蚂蚁金服的风控演进历程，并介绍了立体化风控体系建设。而其分享中最引人关注的当属“蚂蚁风险大脑”，它过去为蚂蚁金服业务“保驾护航”，现已为众多金融监管部门、金融机构以及企业提供安全技术能力，做好安全的“守护人”。据悉，蚂蚁风险大脑的监管科技系统，利用了人工智能、大数据、云计算和区块链等领先科技手段，能够协助各地监管部门对类金融机构进行多维度的风险排查，实现涉众风险、经营风险、合规风险等全领域动态扫描，通过知识图谱挖掘，让监管部门拥有“透视眼”，发现关联机构间的潜在风险，从根源处识别出疑似金融欺诈团伙，并且还可以帮助监管构建地区及行业整体风险指数，快速识别地区及行业的风险“水位”，掌握宏观金融风险趋势变化，现已与北京、天津、河北、温州、广州、重庆、西安等全国10地金融监管部门建立合作。在这个数字时代，几乎所有领域都在发生“数字蝶变”，几乎所有领域都在呼唤风险防范和安全建设，特别是金融领域，今年年初至8月中旬全国各地500余家P2P平台现“爆雷潮”，造成无数投资人损失惨重，这也对相关政府监管部门提出了更高监管和保障市场参与主体安全的要求。对此，为进一步推动防控金融风险与群防群治有效结合，切实提升社会金融安全意识，调动群众发现举报涉嫌非法金融活动线索的积极性，在助力金融监管部门进行风险排查的同时，蚂蚁金服利用“风险大脑”的技术力量做支持，与多地共建金融知识宣教和线索举报平台，推进普惠金融进程。例如，蚂蚁金服和北京地方金融监督管理局合作的“金管卫士”小程序，用户可以打开支付宝首页，搜索“金管卫士”进入小程序，通过观看学习相关视频、漫画和图文，了解非法集资、传销和金融诈骗等非法金融活动惯用套路，提升社会公众的金融风险防范意识。同时，针对可疑平台，用户可以在线进行线索举报，并根据自身意愿选择“实名举报”还是“默默举报”，还可查询相关举报反馈结果，发动民众的力量来举报违法违纪的金融乱象，共同参与监督，净化市场环境，从而更好地维护自己的合法权益。“改变世界的不是技术，而是技术背后的梦想和责任”。蚂蚁金服所倡导的理念“科技是暖的，世界是平的，暖科技正让世界变得更加平等”，这也是他们所努力付诸的行动，不断利用自己的优势为社会做贡献，认真践行社会责任感，共创一个更加平等可信的金融环境。

2019年1月4日，蚂蚁金服ATEC城市峰会以“数字金融新原力（The New Force of Digital Finance）”为主题在上海举办。稠州银行副行长程杰、蚂蚁金服副总裁刘伟光、蚂蚁金服金融科技产品技术总监杨冰、蚂蚁金服创新科技部资深总监李杰力等出席本场峰会并发表主题演讲。本次大会，蚂蚁金服带来了2019金融科技趋势预言、前沿技术产品以及生态服务能力三大方面的发布，释放数字金融新原力。会上，蚂蚁金服联合20家银行、保险、基金等金融机构，共同发布“2019金融科技趋势预测”。蚂蚁金服科学家，中国农业银行、华夏银行、中国外汇交易中心、光大科技、中国人寿养老保险、博时基金等蚂蚁金服合作伙伴嘉宾，基于各自的开放实践，对区块链、数据智能、海量金融交易等技术将在金融行业带来怎样的变化，发表了自己的见解。蚂蚁金服副总裁刘伟光指出，数字化转型是技术与商业模式的深度融合，银行数字化转型是一个逐步递进的旅程，蚂蚁通过全面开放与探索，不断助力金融机构创造数字化转型里程碑，也期待与更多合作伙伴一起，预践数字金融之旅。演讲中，刘伟光与稠州银行副行长兼CIO程杰一起展示了稠州银行建立全新的数字化DNA的创新实践。据了解，大会上蚂蚁金服推出了移动开发、分布式数据库、分布式架构能力等技术领域的升级发布。其中，一直凭借强大的客户端增效能力、坚实的中台运行能力而供不应求的蚂蚁蚂蚁金服移动开发平台mPaaS（mobile Platform-as-a-Service）升级到3.0版本，“新版本以智能技术助力客户构建自己的超级 App，企业可以拥有等同于支付宝的能力，包括技术、生态、业务等“，金融科技产品技术总监杨冰介绍。除此之外，蚂蚁金服宣布启动“链创·未来”为主题的区块链创新大赛，大赛将以蚂蚁区块链BaaS平台为基础，鼓励企业和开发者以场景驱动，在各行各业中进行应用创新。据介绍，通过两年的沉淀，蚂蚁区块链完成了核心技术的突破和场景打磨，以供应链金融为例，蚂蚁双链通通过为行业搭建开放式信用流转平台，破解过去融资难、收款难等小微金融难题，助力小微企业、银行构建可靠稳定的供应链金融生态。2018年9月云栖ATEC大会上，蚂蚁金服副CTO胡喜宣布，蚂蚁金融科技全面开放，支付宝将与数百家合作伙伴以及广大技术创新者一起，为行业提供通用和行业解决方案。现在，在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，其全面开放的技术菜单达数百种，包括金融安全技术、海量金融交易技术，金融风控技术，金融智能，生物识别等；行业解决方案则包括数字银行解决方案、数字保险等解决方案。胡喜表示，“我们希望通过技术开放，可以帮助行业打造100个、1000个支付宝、网商银行。”蚂蚁金服ATEC（Ant Technology Exploration Conference）科技大会是由蚂蚁金服举办的、面向全球合作伙伴与技术专业人群的前沿技术探索大会，致力于通过对先进的前沿技术探索与讨论，为世界带来平等的机会。未来，ATEC城市峰会的足迹将陆续覆盖国内外更多城市。

数字经济时代，银行如何进行数字化转型？业务模式转型与科技转型如何协同并进？2019年1月4日，在上海蚂蚁金服ATEC城市峰会上，浙江稠州商业银行（以下简称“稠州银行”）副行长兼首席信息官程杰分享了稠州银行的数字化建设实践之旅。我们可以看到，一家立足小微金融服务的银行机构，如何构筑全新的数字化基因，以科技创新快速进入数字化时代。对于未来金融科技、数字银行的发展，程杰认为，银行数字化转型的关键是盘活数据资产打造核心能力，践行数据驱动的应用场景建设，广泛运用金融科技手段，提供极致体验的智能化金融服务。稠州银行，有着CBA那样追求更快、更高、更强的精神。据了解，稠州银行成立30年来，一直致力于做小微企业和市场商户的商贸金融伙伴。从扎根全球最大的小商品集散中心义乌，到全面进入长三角经济圈核心区域，稠州银行始终紧随市场经济的步伐，关注小微客户的金融服务需求。自2006年起，稠州银行实施“走出去”战略，全面布局长三角。截至目前，稠州银行的体量规模达到资产规模2000亿元，分行14家，范围覆盖9个省。到了新型数字化时代，稠州银行开启了零售业务转型与数字化科技转型的创新战略，来保证银行高效、高质量的金融服务。程杰指出，普惠金融服务需要不断突破边界，包括数据的边界、服务半径的边界，以数字化的方式降低边缘成本，突破商业模式、个性化服务的瓶颈和制约。程杰表示，在新型互联网时代，数字化转型与开放融合对银行而言势在必行。程杰表示，“所谓数字化转型是什么呢？一句话概括：我们希望能够在银行建立一个数据大脑，在所有业务领域实现数字驱动。”这不是一个数据报表可以解决的概念，程杰解释道，从应用场景端到整个金融服务旅程，都希望银行运营过程中用数字说话，包括了解客户画像的个性化，需求的差异，以及实现生态场景建设、大数据风控机制的建设，建立包括——数据资产化、决策数字化、业务线上化、流程敏捷化在内的四大能力。然而，打造数字驱动的金融应用服务，看似是前端的体验优化，事实上，是背后的IT系统中涉及核心系统架构、数据中台、移动开发等缺一不可的敏捷能力中心建设。程杰指出，过去，银行的数字化创新实践面临着几大瓶颈，比如App框架缺乏大规模客户业务支撑，运维效果大大地影响力客户体验；内部系统紧耦合，新功能开发工作量大、周期长；数据平台建设与业务发展存在鸿沟，业务上无法立刻感知这些平台带来的能力，数据智能能力受到制约……这也形成了稠州银行与蚂蚁金融科技合作的数字化转型战略路径与目标——建立稠州银行全新的数字化DNA！程杰介绍，这包括：打造数字化银行的技术基础，构建以“数据、互联网、账务驱动”为核心的“三核驱动”，建设全新分布式互联网核心；建设数字银行的生态场景，打造全渠道数据运营生态圈；建立数字银行的管理文化，形成完整生命周期的全行级数据规范体系；激活数字银行的数据资产，构筑以“AI”为基础的全业务数据决策能力。基于这些基础建设，探索助力银行实现稳定、高并发的账务处理能力，以及灵活、敏捷、开放的服务能力，和盘活数据资产、实时数据决策的服务能力，打造极致的用户体验，适应数字化时代的市场要求。据介绍，数字化1.0从移动端开始，着力于改善客户连接。而到了数字化2.0时代，银行重点在于通过云计算、数据智能等技术，来建立数字化企业三大核心竞争力：技术敏捷能力、数据智能驱动能力、业务敏捷能力，打造数字银行的敏捷能力中心，降本增效。程杰表示，“银行数字化转型是一个复杂的过程，但很庆幸，我们已经踏上了数字银行之旅。”目前，在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，蚂蚁全面开放的技术菜单达数百种，包括金融安全技术、海量金融交易技术，金融风控技术，金融智能，生物识别等；行业解决方案则包括数字银行解决方案、数字保险等解决方案。蚂蚁金服副CTO胡喜表示，“我们希望通过技术开放，可以帮助行业打造100个、1000个支付宝、网商银行。”

深圳真实学妹上门服务(131-8906-4278)威电同步深圳找小妹上门服务，欢迎来电，我们将最好的服务送到你的身材。

作者：WeTest小编商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/435.htmlWeTest 导读北京时间12月21日下午1点整，2018年度腾讯WeTest技术交流开放日在上海举办。盛大、巨人、电魂、bilibili、方趣等十余家来自不同优秀企业的测试技术负责人均来到现场，共同见证了WeTest所带来的技术魅力。_WeTest是由腾讯官方推出的专业级一站式品质开放平台，主要提供云测、性能、安全、舆情分析等全方位专业服务。而此次技术交流开放日的举办旨在进一步实现平台创立至今所秉承的“开放、分享、共赢”的目标愿景，将WeTest推向更广阔的舞台为更多合作伙伴助力研发。（图：2018年度腾讯WeTest技术交流开放日流程图）时代的进步昭示着市场的革新，而要想在如今市场上取得成绩，就必须明白“品质”乃是企业成功的根基。本次开放日将“品质成就未来”定为主题，意在助力各企业共同提高业务水平，重视产品品质。WeTest总负责人方亮先生在开场辞中这样说道：“严冬的一丝暖阳已至，曙光初现。来之不易，务必珍惜。我们更加需要尊重用户，尊重市场，重视产品品质，才能打好未来这场仗。品质成就未来！”。致开场辞后，腾讯WeTest的主要负责人和技术人员为在场的嘉宾真正打开了通往高阶测试技术的大门。（图：腾讯WeTest沉淀十年致力打造质量开放平台）新时代手游的出现为游戏领域增添了无限的可能，而「腾讯WeTest高级项目经理 - 巩宁宁」讲述的《S级手游的锻造之路》希望通过WeTes将腾讯质量管理体系与质量标准与行业共享，为行业开发者提供效率和质量保障，提升行业品质；「腾讯Turing Lab总监 - 张力柯」在现场谈论了《自动化测试新纪元：从AI测试到AI分析》从自动化框架、异常检测、数值分析三个大方面层层揭开了AI技术的面纱，以及深度学习和传统图像识别方法在图像异常检测方面的应用和使用Deep&Wide模型在游戏数值模型分析等多个案例。不仅如此，腾讯高级测试开发工程师们也一一在现场从不同层面讲述了WeTest的种种前沿科技，「腾讯高级测试开发工程师 - 黄贵江」在基于智能探索的兼容测试分享中介绍了更加简捷、场景覆盖率高的方式——场景遍历，用户只需标记场景即可完成测试；「腾讯安全SR项目负责人 - 王枭」与「腾讯高级测试开发工程师 - 王建行」通过手游安全渗透测试和手游宕机漏洞检测两个维度讲述了SR手游安全的技术核心，分享了WeTest如何利用协议、函数、内存、变速等多维度深度漏洞挖掘，让游戏在上线之后免受漏洞困扰，并通过高强度多策略百万级测试用例对服务器进行Fuzz测试，给游戏服务器以稳定保证。（图：SR手游安全测试深度覆盖）（图：《龙之谷手游》服务器选择界面）而腾讯WeTest的云测、安全、压测三大线的产品经理则把《为质量赋能》从兼容&功能、安全、压力测试三大方面进行了阐述，详细解读了“腾讯WeTest - 游戏测试解决方案”，让到场嘉宾对测试服务有了更深入的了解；2017年ARPG《龙之谷手游》火爆异常，「腾讯高级测试开发工程师 - 童立舟」则借由此款游戏的压力测试，将百万级在线游戏的服务器性能测试进行了一场别开生面的介绍，将开场辞中“重视产品品质，才能成就未来”的理念再次强调，至此本次交流会的分享环节圆满结束。（图：2018中国移动游戏质量白皮书）如若说开放日的前半程是在探讨应该如何夯实现在、创造未来，那么这部分就是准确总结过去、合理展望未来。《2018中国移动游戏质量白皮书》将本年度所有值得重视的发展关键点一一记录，并针对典型问题提出优化建议。一共从硬件情况、兼容情况、安全情况、服务器性能、客户端性能、小游戏测试、手游舆情七大方面呈现了2018年度手游质量方面的现状，其中更是包括了本年度最火爆的战术竞技类游戏舆情和性能分析、异形屏占比升高等热门看点。在技术与数据的海洋中畅游之余，腾讯WeTest技术交流开放日上也准备了年度答题抽奖这样的趣味环节，iWatch4、王者荣耀吕布机器人、智能音箱等精美礼品也在现场被相继送出。当然，现场嘉宾和腾讯WeTest的技术专家们自然不会放过这样一个交流经验的好机会，抽奖结束后现场马上展开了技术交流研讨，直接把讨论气氛推向了高潮。（图：2018年度腾讯WeTest技术交流开放日现场）腾讯WeTest在Android平台碎片化愈加严重的时代背景下应运而生，如今已然成为了覆盖产品在研发、运营各阶段的测试需求的高端品质开放平台。腾讯WeTest将会把“开放、分享、共赢”的精神始终贯彻，2019年腾讯WeTest还将在全国各地举办行业沙龙，将WeTest的高品质保证带给更多人，如果你是对品质有着执着坚持的开发者那么腾讯WeTest肯定会给你一个满意的答复，更多行业资讯可预约下载《2018中国移动游戏质量白皮书》了解。_点击https://wetest.qq.com/whitepaper/2018 即刻预约《2018中国移动游戏质量白皮书》。如有任何疑问，欢迎联系腾讯WeTest企业QQ：2852350015

小蚂蚁说：你们都很关心的 “OB双11大促实战分享” 专题来啦！本系列将为你系统性的介绍OceanBase支撑蚂蚁双11背后的技术原理和实战分享。从平台到架构，再到实现，一起来探索蚂蚁双11这场神秘的技术之旅吧！背景伴随着蚂蚁业务的蓬勃发展，特别是每年双11大促不断创造新的高峰， 交易支付核心链路提出了未来实现百万笔支付/秒的能力 。为了实现这个宏伟目标，特别是提高数据库层面分布式扩展能力，如原生sharding/分布式事务优化，OceanBase 2.0分布式数据库应运而生。百万支付传统数据库扩容方案，主要是依赖分库分表拆分进行水平扩容，蚂蚁数据库初期也是同样思路，通过LDC单元化改造，核心表按用户UID维度拆分成百库百表。但是随着业务发展，特别是2017年的双11大促，峰值需求已经远远超过单库单机的最大容量。针对这个问题，我们使用弹性架构，即在大促前，新增两套弹性数据库，多套库共同支持大促峰值。弹性架构虽然解决了大促容量需求，但是也存在一些缺陷，业务在数据路由、后期维护及数据配套设施都非常复杂繁琐。有没有更优雅的分布式数据库解决方案，即只使用一个库，就可以支持百万甚至更高的支付峰值，OceanBase 2.0分区提供了完美的解决方案。OceanBase 2.0整体架构原理分析OceanBase 2.0分区方案思路和传统的分库分表拆分一样。我们在交易支付核心库上，在原有百库百表的基础上继续按用户UID进行更深层次拆分，每个分表再拆分成多个partition，应用端只看到一张表，在用户无感知的前提下把数据拆分到无限多的机器上，突破单机性能瓶颈，自动负载均衡，从而实现百万支付的能力。同时为了极致性能，OceanBase 2.0提供了partition group功能，将业务使用的多张逻辑表（table_1、table_2、… table_n），按共同的partition聚合在同一台服务器上面，从而避免了分布式事务带来的额外开销。OceanBase 2.0分区方案关键点：APP端请求SQL，带上包含分区的字段—UID信息（如payment_id列)。SQL如果没有分区信息，则在OBServer端并行计算优化。OBClient负责分区计算及路由，确保第一跳准确定位到对应分区所在服务器，避免远程执行。OBServer端基于生成列partition_id进行内部分区，不侵入业务。OBServer端约束描述多维度分区，实现分区裁剪功能。优点：业务友好：不改变SQL语义，应用代码不感知分区信息。架构通用：约束功能，实现分区裁剪；OBServer提供兜底访问能力。高性能低成本：使用低配置服务器，自动负载均衡，资源利用率高。OceanBase 2.0性能优化分布式事务消除：partition group方式，事务涉及所有表的partition按照分区键存储至同一物理机。两阶段提交协议优化：结合事务与日志，事务prepare成功后内存不用持久保存状态，按需从日志中查询；commit状态持久化转换成后台批量完成。Commit异步化：异步化后Worker不等待继续执行队列中下一个请求，日志持久化成功后会异步回调。内存分配器优化：组织了两层映射关系，既要提升性能又要支持大量分区。存储优化：数据编码技术实现高压缩。优化结果：整体性能OceanBase 2.0版本较OceanBase 1.4版本性能提升50%，存储空间节省30%。总结2018天猫双11全球狂欢节成交额超过2135亿，OceanBase 2.0成功经受住了考验，全面支撑了支付宝核心链路 ，平稳抗住0:00:00时的峰值压力，夯实三年战略“百万支付”的底盘能力。OceanBase 2.0还有很多重要特性，比如分布式全局索引、分布式全局一致性快照、分布式存储过程、索引实时生效、Flashback闪回功能等，这些新功能将强有力支持企业不同业务场景下的持续创新。加入我们【数据库智能化开发】岗位描述：1、负责蚂蚁金服数据库智能运维平台应用架构设计和实施落地，使系统体系化并具有前瞻性，能快速发现异常和风险隐患，自动识别原因并修复故障源/风险点，实现self-healing、self-scaling、self-tuning的自治数据库目标；2、负责构建数据库统一技术风险、业务容量和稳定性的数据模型，以数据为支撑驱动诊断、容量、高可用、业务最佳实践等核心问题的数据库智能运维发展；3、独立完成大型项目的系统分析设计，并负责核心模块研发，完成系统Code Review的任务，提供相关性能以及安全的建议。【数据库平台前端开发】岗位描述:负责蚂蚁金服数据库DevOps平台产品的前端研发，通过专业的前端技术能力为整套数据库产品提供优秀的前端解决方案。【数据库平台后端开发】岗位描述：1、负责蚂蚁金服数据库基础平台、容器化、高可用体系等领域的平台研发；2、通过平台化思路，持续优化系统维护工作效率，把控技术风险，用工程的思路解决遇到的问题；3、负责蚂蚁金服数据库智能平台应用架构设计和系统实施，使系统体系化并具有前瞻性，能快速发现业务风险和及时管控；独立完成大型项目的系统分析设计，并负责核心模块研发；负责完成系统Code Review的任务，确保相关代码的有效性和正确性，并能够通过Code Review提供相关性能以及安全的建议。【数据库SRE】岗位描述：1、负责数据库高可用平台体系、基础设施的开发和建设，追求100%的服务持续可用、秒级故障恢复能力；2、负责数据库成本优化，通过新技术、新产品、新方案全方位地优化系统性能；3、负责数据库相关平台和工具产品的建设，持续改进业务研发和系统维护效率，用工程的思路解决遇到的问题；4、负责数据库架构设计，基于高可用、高性能、防资损等视角，与业务团队一起进行数据架构设计；5、负责公司重大业务活动（如双11/双12）数据库保障，致力于让用户感觉丝般顺滑；6、负责数据库新技术的探索及落地，如存储计算分离、数据库容器化等。可直接发送简历到 qijie.tianqj@alibaba-inc.com，我们等的就是你！

小蚂蚁说：双11十年间，交易规模的指数级增长不断挑战人们的想象力，而对蚂蚁技术团队来说，这不仅是一场消费盛宴，而是无数次濒临压力和焦虑极限的体验，更是技术的练兵场。如今双11对蚂蚁金服而言，已经绝不仅限于一个技术项目，而更像是一个社会化工程，可以叫做「连贯的，社会化的技术大协作」。图 | 东方IC CYZONE特写，大时代惘闻录图 | 东方IC CYZONE特写，大时代惘闻录支付宝团队不正像那尊红漆雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。「双11」就在眼下了，但蚂蚁金服的新园区里气氛明朗，人群也没往年那么匆忙。进园区时，出租车司机左手扶稳方向盘，右手比划着说，秋天是杭州最好的季节，当然啦，春天也不赖。阳光猛烈，洒在园区的楼群上，映得金栗色玻璃深邃又清亮。这座新园区里尚有很多事不为人所熟知。每3分钟会有1人在2号楼门口左手边垃圾桶上捻灭烟头，吱呀作响；访客大厅的姑娘每天用胖大海跟人参片泡4壶茶，12个玻璃杯倒扣，杯子把统一偏右30度；园区身着橙色外套的保洁员不间歇地扫落叶，她们每天工作8小时，3班倒，总在推车上预备3个喷壶，以及1个保温杯；每个花坛里，通常能用竹质夹子够出三个烟头或纸片。这里的秋天昼夜温差只有6摄氏度，但早晚都有人衣着单薄；穿冲锋衣的外卖员打手机时，话筒离开嘴边20公分，嗓门平均70分贝；下午时分，很多餐馆的员工们蹲在门口抽烟，只有星巴克客流不断，这里的大蛋糕与迷你蛋糕预定时间都是3天，收银员也偶尔会用墨色水笔给姓董的先生标注Mr Wang；员工餐厅每天分四次供餐，楼群间额外排列着18家餐饮门店。楼内有超过1000平米的免费健身房，私教价格仅为外边的一半，穿耐克跑鞋的姑娘每天会带着她的柯基犬来同时使用两台跑步机，尽管她的身型已没什么可挑剔。当你在下沉广场跟第四个人搭话后，套着夹克衫的保安会盯着看，在你发毛之前问及身份，噢，是记者，别介意，履行职责嘛。这是造价超过11亿元，面积18万平方米的蚂蚁金服新总部，设施功能齐全，堪堪媲美小型城镇，是 NBBJ 建筑事务所的手笔，也被叫做「蚂蚁Z空间」。功能强大的综合体建筑容纳了这里的杭州人与新杭州人，注视着他们的每一单生意，每一次创新，这里承载上万人的财富与梦想，也记录着每个个体的骄傲与焦虑。双11十年间，交易规模的指数级增长不断挑战人们的想象力，而急速扩张背后，对技术团队来说，是无数次濒临压力和焦虑极限的体验。想象力和焦虑最初给蚂蚁金服技术团队结出了一张网，又织就成细密厚实的茧壳。从2010年开始的三四年里，人们总会在双11的消费前端感受到一些使用体验的卡顿、不舒适，而内里则是这批工程师与欲望、想象力的博弈乃至搏斗，并在很多个逼近焦虑极限的瞬间，不断打破桎梏。2017年8月份，蚂蚁金服正式启用了这座名为「Z空间」的新园区 | 图虫创意「为了几十秒，值吗？」杭州入秋的早晨，凉得很，黄勇（花名展一）起个大早，跟几位同事结伴跑了趟灵隐寺。这千年古刹在深山，向来香火旺盛。这几年，寺庙时兴环保，免费发清香，他请了三炷，点上，拜拜。采访时，我问拜的哪位菩萨，黄勇皱皱眉头，乐了，「还真不认识」。烧香的心可是诚的，况且，来许愿的人，没几个比他的愿望还大，作为今年双11支付保障PM（项目经理），他得事无巨细地操办这个事关几亿人的项目。每逢双11，蚂蚁金服的项目组成员们总要供上关二爷，穿上红内裤，换上红战袍，存几瓶红酒，烧几炉香。按支付宝双11保障团团长陈亮（花名俊义，技术风险部研究员）的话来说，这是对技术的敬畏。可事实上，要敬畏的绝不仅仅是技术这一件事，双11作为枝节空前庞杂的项目，每个事物的细节上都有无数个随机的可能性，早已超出了人能控制的边界。黄勇能做的就是制定「容灾」机制，尽力去逼近那个不可能到达的「确定性」。举个例子来说，在采访当天，黄勇刚刚给所有11月10号晚上要进光明顶（支付宝双11作战室）的成员发了邮件，仔细交代了「如果当晚茶杯在电脑上打翻了怎么办」这个主题。2012年，负责支付宝双11项目的PM同事从西安请回一尊皮影关公像，大伙觉得新鲜，纷纷敬上香烟、酸奶跟水果。自打那会开始，每逢重要的项目启动，总有人提前往公司请关二爷。创业邦这次拜访蚂蚁金服时，作战室里就供着一尊二爷铜像，该上的供也早都摆上了。请二爷似乎也开始带来好运，那位请铜像的同学，前年双11还在公司里抽到一次大奖。某年双11，马云带几位合作伙伴在西溪园区参观，登上光明顶（支付宝双11作战室）的时候，一位女性投资人吃惊地问，你们工程师居然时兴拜关公？俊义就笑，还是那个说辞，敬畏。信仰也好，敬畏也罢，双11显然都值得。十年里，从最初几乎不太被人感知的促销活动，由欲望、情绪、责任感和创造力混合驱动着增长，长成一个不断突破想象力极限的庞然大物。2009年，首届双11购物节的单日成交额是5000多万元，一个对比是，当年支付宝的日交易额最高突破了12亿元。「记得有几十个品牌参与，当时对它的感觉就是，淘宝做了个活动」，支付宝事业群总裁倪行军（花名苗人凤）回忆称。但他没有预料到，所有人都没预料到，从第二年，双11就开始刷新所有人的想象力上限，如今回头端详增长曲线，它在某些年份里维持着数字量级的增速，那线条着实显得陡峭，但想想吧，处在那个当下，未知和增长给人们心理带来的是更加强烈的冲击感。在蚂蚁金服CTO程立（花名鲁肃）的记忆里，2010年之后的几年双11，对支付宝技术团队来说，是像电影《2012》一般的巨大考验，「你把一个船放在那里，上面有个大浪，没人知道能不能扛住，扛住就扛住了，扛不住就没了。」这艘大船只能提前按既有的想象力建造，但在应对巨浪时，必须临时补救随机出现的漏洞，随机意味着不确定性，巨大的随机和不确定性就进一步施加给团队更庞大的压力。程立记得，现任阿里云副总裁李津当时在阿里巴巴集团负责双11项目，「受不了的时候，李津要开车到龙井山上，打开窗户睡一宿，他说压力太大了，要吸氧。」2010年，第二次迎接双11的支付宝经历了一次后来广为人知的「4秒惊魂」。11日的23时59分30秒，双11结束前半分钟，支付宝核心账务系统突然报警，资源行将耗尽。当时整个支付宝的账务数据库没有进行过任何拆分，一旦系统崩溃，所有业务都会挂掉，对淘宝和支付宝都会造成灾难性损失。在工程师将一个会计系统的应用关掉，释放出来资源时，离数据库崩溃只剩4秒。单就技术本身，在当时就已经是一笔永远测算不清楚的账。2012年双11之前，支付宝技术组已经把能想象到的压力测试做了个遍，但当晚高峰期还是出了岔子，运维工程师巩杰（花名袁越）记得，当时后台一条数据通道设置的阈值太低，导致短暂宕机，但系统认定为无法响应，于是自动将其剔除了，随后服务器一台接一台地挂掉，「跟雪崩似的，导致几十分钟里交易一直在抖动」，直到做了降级，切掉一部分流量之后，系统才恢复正常交易——按程立的说法是，那根保险钨丝被高频交易熔断了，临时搭上一根铜线才应付过去。此时，过于庞大复杂的系统，人力已经无法完成全面有效的测试了。巩杰说，因为有前两年数据库无法承压的情况，2012年已经在应用和DBA层面做了大量的压力测试，但最终出问题的，恰恰是前面还没压到的「路口」。采访中，俊义苦笑道，当时每年双11都信心满满，每年又都过得提心吊胆。在双11压力最大的那几年，整个支付宝技术团队每年要花费几个月乃至半年时间来「练兵」，做各种技术结构调整，系统测试。俊义最初产生过疑问，整个团队花费出的绝大部分时间精力，只是为了贡献给双11最高峰的那几秒。「非得这样吗？」「值吗？」但时间会赋予所有原本未知事物以终极的意义，双11正是这样一个把意义逐渐延展开的时代产物。「在当时，淘宝是我们最大的客户，我们必须服务好」，俊义说。按照马云早年的讲法，在客户关系之外，淘宝天猫和支付宝更像是夫妻关系，也正是在淘宝天猫的业务倒逼下，支付宝团队的技术能力被空前地激发，一位今年入职的工程师毫不讳言，他入职蚂蚁金服的核心吸引力就是双11，「对工程师来说，再没有比双11更值得挑战的项目了。」巩杰也是后来才意识到，某信用卡团队早先在实验室环境里实现的数万笔每秒的交易峰值，早就被支付宝在实战里远远抛在身后。2017年双11，支付宝的交易峰值就达到了25.6万笔/秒。按照资深技术专家李铮（花名祢衡）的说法，技术团队最近几年已经把双11两天48小时的工作量做了很细致的拆分，“我们做了非常详尽的作战手册，它有很多的步骤，按不同的时间点，你要去执行。”技术之外，双11是个在更广泛的范围内牵扯着不同部门，不同团队，不同企业的庞大协作系统。蚂蚁金服集团副总裁陈亮（花名关胜，品牌与公众沟通部门负责人）记得，某一年的双11当晚十点钟前后，一家国有大行银行的交易系统内的一百万个单号发光了，后续单子无法生成，于是当晚最后两个小时，所有源自该银行的支付订单都无法执行。「总会有你无法预想的问题出现，我们做好所有准备，剩下只能兵来将挡水来土囤了。」想想啊，就好比火箭升空一样，倪行军敲敲桌子说。多少软硬件技术环节，多少个零件组装拆卸，在设计制造的过程中，只能穷尽所有人脑可以企及的可能性去做测试，但在点火那一刹那，等待它的是圆满功成还是原地爆炸，你只能束手以待了。倪行军觉得，无论是技术人员拜关公、烧香还是公关团队的预案，都证明了蚂蚁金服团队对双11的敬畏心。2013年5月，支付宝下线了最后一台IBM小型机，随后逐渐以自主研发的OceanBase数据库替代了Oracle，完成了去IOE工程。如今双11对蚂蚁金服来说，已经绝不仅限于一个技术项目，而更像是一个社会化工程。程立说，如果为它定义一个清晰的组织概念，可以叫做「连贯的，社会化的技术大协作」。双11作战室里的鲁肃（程立）| 受访者供图一面敬畏，一面狂奔蚂蚁Z空间的楼群维持着古怪的几何形状，像个「撅着屁股」的Z字，又像个扭动起舞的水泥巨人。但与外部怪异的建筑设计、杂乱的人流相反，在楼宇内部密布着闸机与证件机器，构建起坚固的秩序和准入流程。室外，巨大的红色人形雕塑朝着人流入口鞠躬，姿态谦逊，气势却浑然不可当。支付宝团队不正像那尊雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。这十年间，在双11之外，他们也有很多焦虑要去消解。被问及在支付宝工作十几年间最难忘的瞬间，倪行军和陈亮的首选都是那次年会。2010年1月21日，支付宝公司年会，此前内部并没有太多源自自觉的危机感。遥遥领先的市场份额与灼灼亮眼的业务数据，一切看起来十分顺利。但年会一开场，人们就发现气氛就有些怪异。会场高音喇叭里首先传来指责、抱怨、无奈与批评，这些声音是来自客服电话录音里的客户投诉。但现场事态发展，完全不只是「反思」而已。陈亮到了会场，才收到马云等阿里集团组织部的高管们将要到场的消息。随后，客户满意中心的代表上台，表达了「我们的体验如何糟糕，用户如何承受着折磨」；BD团队则指出「合作伙伴是如何对支付宝的高期望，同时又是如何的失望和无奈」。马云现场发火了。「烂，太烂，烂到极点」。陈亮记得，这是他多年来唯一一次在公开场合看到马云发脾气。马云毫不客气地指出，支付宝在很多问题上太过保守，如果不重视用户体验，「将慢慢死去」。这显然跟支付宝团队自我评价的结论相去甚远，事实上，在那个时点上，如果横向对比来看，支付宝的产品设计和市场占有率表现绝不算差，团队甚至把2009年定义为「用户体验年」。但回头看，当时在PC端的产品体验确实很不理想，每次支付都需要解决控件、插件、外接U盾一堆问题。 时任阿里巴巴CTO的王坚也给了一句非常严厉的评价，「自娱自乐」。这甚至使倪行军当下有点懵，他记得在年会之后一段时间里，一度陷入严重的自我怀疑，「搞了这么多年技术，怎么变成自娱自乐了？是不是我们对技术的认知出了问题？」后来他反应过来，差池是出现在从技术到产品、到业务、再到客户之间的对话环节。做客户体验，单由使命与愿景来驱动不够。他原本认为的应该如何运作，与用户的现实期待之间，鸿沟已现。整个中国的支付行业按照支付方式演变可以分成三个阶段：2009年-2013年，从网银支付到快捷支付；2014年-2016年，移动支付崛起；2017年-2018年，则是指纹和刷脸支付渐成主流。如今回头看，那次年会对整个蚂蚁金服公司来说都是个至关重要的节点，在此次转型的推动下，支付宝从网银支付迈进了快捷支付时代。「生生被逼出来的」，俊义回忆道，「如果那时候没有快捷支付，整个中国移动互联网的进程至少会落后两三年」。微信支付加入之前，支付宝曾有十年时间只能自我调试，寻找发展坐标。而当前者入局，支付宝团队的反应是：哇！我们有竞争对手了。「我们从没有遇过像这样的竞争对手，竞争是很正常的事情，但结局取决于竞争对手的能量，微信支付是非常值得尊敬的一个竞争对手。」陈亮如是说。微信支付出现，促使蚂蚁金服又一次推进意识形态的提升。如今说来云淡风轻，当时可是风起云涌，情绪百般垂丧。时间回到2014年1月26日，腾讯推出微信红包，后者立刻以病毒式传播的方式活跃在微信群内，并在除夕夜全面爆发。数据显示，除夕当天到初八，超800万用户参与了红包活动，超4000万个红包被领取。与微信红包这面的热火朝天形成明显反差的是，支付宝的「讨彩头」反响平平。后者推出于23日，还早了3天。「微信一个红包就超过支付宝8年干的事。」这句话很快流传起来，马云后来则用「珍珠港偷袭」评价腾讯推出微信红包一举。陈亮对这件事情对记忆尤其深刻，他参与了支付宝红包的产品讨论。因为也在广东工作过，知道当地有讨红包的习俗，于是他给出了做「讨红包」的建议。但微信做的是「发红包」，陈亮回想，当时讨论过程中，似乎也有人提出这一点，但产品设计最终并未将其采纳。 其实，即便支付宝当时采用了发红包的设计，在那一阵上也未必有胜算——没有关系链，没有社群，没有从交易体系到账户体系的整体准备。但陈亮仍然感到懊悔，控制不住的懊悔，甚至责怪自己技不如人。眼看着媒体群里纷纷扬扬的红包雨和赞扬声，陈亮都不想上微信了，「不想说话了，不敢说话了」。 他想去友人处寻得开解，想驳斥那句一个红包顶八年的说法，但他刚开口就沉默下去，市场反应已然说明一切。可他还是在心里翻来覆去地想，怎么我们没有想到人家那个点子，怎么就没有呢？ 但事情过去也就过去了。尽管公司层面的焦虑一直延续到2016年，但陈亮已经学会将焦虑情绪摒除在自己的生活之外。焦虑毫无用处这件事已被证明——前两年的焦虑除了让他自己难受紧张、动作变形外没有产生任何意义。其实，接受这种量级的竞争，或许某种意义上也是在接受命运馈赠。陈亮后来总是被年轻同事认为对困难事物的感受很迟钝，他自己觉得原因在于再没有过境况更加艰难的时刻了。再碰到困难时，总有一种消解的情绪在，「最难的时候都过来了，这些算什么？」而支付产业则更加受益于两家顶级公司的竞争推动，中国支付技术在国际上一骑绝尘。2017年年末，西班牙《世界报》刊文表达了对中国支付产业的看法，给出的结论叫做：「中国的支付革命堪称中国史上最大的技术革新之一。」2018年10月19日晚，蚂蚁金服在Z空间举办HighMa音乐节 | 东方IC技术的价值观其实从2010年双11的「4秒惊魂」之前，支付宝技术人员就意识到，使用IOE商用设备（IBM-服务器提供商，Oracle-数据库软件提供商，EMC-存储设备提供商，三者构成了从软件到硬件的企业数据库系统）与开源软件，已经不能适用于双11交易量指数级增长对技术支持的要求，尤其是在谁也不能完全预设到当晚状况的时候。即使能支撑，成本也将是天文数字。支付宝决定去IOE，自主研发分布式数据库，转云计算，OceanBase项目随即启动。俊义记得，他在支付宝做的第一个技术改造项目是拆分数据库。当时还不是因为双11，单纯是因为支付宝网站交易量涨得很快，数据库扛不住了，不拆，业务就无法增加。这是在2008年。2010年，俊义又拆了一次数据库。这次，他将上次拆出的两个数据库中的交易数据库，拆成10个小型机。这时已差不多算是为去IOE铺下基础。但很快，10个小型机也不够用了。 2011年的双11结束后，应用服务器与数据库的连接已到瓶颈，容量没办法再增加，换句话说，IOE集中式强大单点无法满足阿里特别是当时淘宝爆炸式业务增长应用的模式，同时也限制了技术潜力的发挥，另外，由于IOE是专用设备，对机架、电力、网络存在单独设计的要求，成本压力也已经非常大。 从2010年1月启动，到2011年7月完成商品库的去IOE（经历读写分离、去小型机、去Oracle和EMC），再到交易等其他核心系统的去IOE，2013年，支付宝最后一台小型机下线，IOE中的I和E都已经被中国自主研发的技术取代，上云完成阶段性进展，这就像造发动机，意味着双11的交易量不会再受到技术制约。不过在第一阶段，每年双11能否顺利通过，还是有点碰运气。从2014年开始，支付宝开始研发和施行全链路压测技术，这就有点像造飞机时候的风洞，造一个实验室，完全模拟当天峰值所有的真实环境，对系统进行压力测试。据2018年大促保障副队长巩杰说，全链路压测对真实用户请求的模拟可以达到与双11当天请求90%以上的一致度。这样一来，到了双11当天，平稳度过的概率就极高了，团队因不确定而产生的焦虑大幅降低。全链路压测作为消除不确定性的“大杀器”，已经成为目前测试系统的常规手段，随着系统的升级，使用频率也在降低，李铮记得，全链路压测技术刚刚研发使用的时候，“恨不得每天都做一遍测试”，而今年的双11准备工作里，每周定期做1-2次压力测试已经足够了。支付宝的双11已经是一个巨大的系统工程，已经无法再完全依赖人脑思考解决所有条线上的问题。所以，李铮觉得，“智能化”是另一个关键词。对系统工程的把控，也正是要辅以智能化全链路压测这类技术手段，才能更加精准高效地解决问题。 11月2日，大促保障团组织了最后一次模拟的全链路压测，万事俱备，只欠东风，就等10日24点一过。苗人凤（左4）与蚂蚁金服同事在双11办公室现场 | 受访者供图对支付技术来说，稳定压倒一切，稳定也意味着一切。一如往年，第10年双11，稳定的重要性依然处于第一位置。稳定之外，支付宝技术团队还有更多追求。在2018年的双11技术保障上，人工干预已经越来越少，因为整个保障系统的智能化程度越来越高。比如，往年筹备双11时，该配置多少计算资源，如何达到最优化的配置，都需要非常有经验的工程师进行严密计算，并进行反复的压力测试，不断调优。但现在，机器可以自动地进行计算和调优。程立打了个比方，双11的支付保障会越来越朝着「自动驾驶」的目标迈进，该往哪开，在哪停，如何躲避风险，保障安全，都是智能的。新的变化还体现在生物识别支付和区块链技术的应用。 在倪行军的谈论中，支付宝对支付的理解，倾向于支付脱媒，到最后，支付时不需要任何载体，人体本身即为最大媒介，当然，脱媒不可完全脱离，但生物识别技术是IoT时代用户参与到数字化场景的敲门砖，任何的场景系统都要首先确定一个所谓的数字身份的问题，而人本身就是最棒的载体，不需要其它的媒介做二次切换。由此，生物识别是可以重塑体验的技术。据倪行军透露，平日应用场景中的生物识别（包括指纹输入、面部扫描等）支付比例已经超过一半，这反映出整体人群对生物识别技术所对应的新支付体验的接受程度，这信号让他觉得，手机应用之外其他生活场景中，扩展生物识别技术用户的时机，已经到来。今年上半年，生物识别技术真正走向规模化商业化，倪行军的预期是先实现规模化，在终端设备达到百万级规模的基础上，根据用户行为与各商业场景连接的磨合情况，再考虑后续的商业诉求。未来，新技术的应用势必重新定义整个商业流程，新的百万级的商业机会将在此诞生。今年天猫双11用区块链技术为1.5亿跨境商品提供原产地溯源，包括比利时钻石交易所的钻石这类大额商品。 变化背后是蚂蚁金服的BASIC技术战略演进及开放，Blockchain (区块链)、Aritificial intelligence（人工智能）、Security（安全）、IoT（物联网）和Computing（计算）这五条线索构成对未来更加清晰的想象力。十年间，蚂蚁金服整个公司都在从中心化向分布式持续变化。人员能力变得更加均衡。俊义记得，早年在双11和很多技术攻关的关键时刻，总会有几位技术大牛同事站出来，在当下拿出过人的洞察与能力，最终顺利过关。但如今，蚂蚁金服公司的整个技术结构益发庞杂，必须形成全局、众人的工程化作战。IT架构从IOE变成分布式，再演化出「离在线混部」。去年有25%是自有服务器处理，55%在云上，20%是离线资源；今年这个比例则会更新到60%在云上，在线与离线分别20%，其间，性能较差的离线机房也能执行在线处理，核心在于资源的进一步合理分配。分布式趋势渐成大势：机房越来越多，从杭州拓展到全国各地；应用系统与数据库越扩越多；团队从支付宝技术团队扩至各个产品线，集团运作从前尚可靠寥寥能力拔尖者把握，如今则需层层分解，整体组织协同作战。「从中心化到分布式」是互联网发展过程中，近年形成的社会关系形态和内容的一大特征。如果将其视作一种价值观的话，作为一家工程师员工占比超过51%的互联网金融企业，它正在被深深影响、驱动并改变着，企业里大量人、事、物，都在明确地呈现这这种趋势导向，这家价值上千亿美金的企业，也正在成为一个由技术价值观驱动业务、团队革新与发展的经典范本。

摘要： 由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目。如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝 “互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里巴巴正用物联网技术解决干旱地区的灌溉问题，通过搭建农业物联网平台，全面监测农作物的生长状态，从而匹配最节约的灌溉方案。12月19日试验区研究人员得出预测结果：一年可以省出1.5个西湖的水。一直以来干旱是困扰人类的重要环境问题，2000年前曾导致玛雅文明的毁灭。在现代中国，干旱问题依然存在，数据显示2017年全国3亿亩耕地就受干旱威胁。导致无水可浇的不只是自然原因，更多是人为导致。在内蒙古巴林右旗，据当地林业局透露，地下水位的大幅下降从近几年开始，耕种者用机电井等设备大规模抽水漫灌，最严重的地区水位下降18米。改变这种粗放型灌溉方式，是阿里巴巴解决问题的切入点。阿里云物联网技术专家谢士杰表示：“精细化灌溉的前提是准确了解作物的生长情况，及周边的环境条件，农业物联网是解决这些问题的前提。”沙漠国家以色列，正是用这一方式实现了农业史上的奇迹，高度智能化的灌溉系统像空气一样随处存在。农产品不仅满足了本国需求，还大量出口欧洲。在国内，智能化的灌溉系统受到成本、技术等诸多因素的限制。但阿里云已经同京蓝科技一起在巴林右旗进行了首次尝试。通过对气温、光照、湿度以及蒸腾量等环境条件的长时间监测，判断环境因子和作物生长各方面的关系，形成专家决策系统，对作物生长环境精准化控制，指挥草原上的灌溉设备浇水。什么时候浇水、浇多少水都由这个智能系统来决定。据估算，巴林右旗因此一年可以节省1550万立方米的水，相当于省出1.5个西湖，当地地下水位也已停止下降。谢士杰表示：“整个过程包含了设备管理、空间管理、数据汇聚、环境监测、水肥一体化等，形成平台后可以更大规模推广。”据了解，阿里巴巴还计划通过物联网在农场侧进行边缘计算，提高灌溉决策的实时性。用科技改造人类赖以生存的农业已经是全球趋势。日本正用互联网实现种植技术与知识的数据化，从而使得这些宝贵的经验被下一代农户和农企继承。美国则在研发可以自己采摘苹果的机器人，提高工作效率。本文作者：阿里云头条阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 只有不停的去挑战自己，永不停歇的思考和不断颠覆自我，才可能保持一点点微小的领先。小蚂蚁说：从“互联网推进器计划”到“成熟一个开放一个”，再到蚂蚁金融科技全面开放战略的公布，这一路走来，蚂蚁金服不断创造技术的里程碑，同时，也缔造出一个又一个的业界里程碑。然而，谁又想到，“蚂蚁的科技开放究竟要怎么做？”今天，我们将分享一个“蚂蚁金服科技开放的故事”。文 | 央行观察作为 “空降” 蚂蚁金服的高管之一，刘伟光刚来的时候颇不适应。刘伟光是蚂蚁金融科技开放的负责人。2017年12月底，在杭州某酒店的一次公司内部会上，刚来公司不久的他，向同事们讲了下他对蚂蚁金融技术开放的战略。那个时候他正在苦苦思索未来的开放格局不得其解，当天人处在正发高烧的状态，状态差到极点。“很多当时的想法连自己都没有说服自己，更不要说别人了”，后来，每次想起这次 “失败” 的分享，刘伟光都觉得挺惭愧的，那就是当时的困境所在。那时的蚂蚁金服，正渐入开放的深水区，从 “成熟一个，开放一个” 决意走向全面开放。如何真正全面、从哪入手等问题都扑面而来。说开放难做，是因为这意味着很多技术能力要从服务C端，跨越到B端和C端兼顾，这中间有一个巨大的能力跨越和需要不断论证的过程。 放眼全球，真正能做到的公司屈指可数，而蚂蚁金服所处的金融行业特殊性，又进一步增加了这个难度：首先，IOE 传统架构下的流程和模式已经在行业根深蒂固，新来者必须提供更有价值的服务；其次，蚂蚁金服自身也有金融业务，合作方难免会有顾忌。因此，如果提供不了更好的解决方案、真正给用户带来价值的话，蚂蚁技术开放的战略就将只是一厢情愿。蚂蚁的科技开放究竟要怎么做？刘伟光和同事们绞尽脑汁地想了几个月，无数个夜晚在黄龙国际的办公室里和旁边的夜宵馆子里带着团队苦苦的进行 “脑暴”。一、“想办法摸到放置在十米高的篮筐”在加入蚂蚁金服之前，刘伟光曾在 Oracle、EMC、Pivotal 等全球顶尖软件公司工作过多年。到蚂蚁后，这是一个全新的行业，且行业在巨变，在老东家的那套玩法已经行不通了。外企最看重的是业务规模和短线收入，但是现在如果他再说自己做了几个 million、几个 billion 的生意的话，在蚂蚁没有人会在意，公司需要的是开拓一种全新的服务模式和用技术来促进甚至驱动生态的做法。这中间需要巨大的脑洞和付出。就像一个篮球运动员，如果让他从3.05米高的篮筐摸到3.20米，只要勤加锻炼就可以达到，这是一种线性的思维和增长，一个不一定恰当的比喻就是：如果篮筐放到10米高让他去摸，怎么办？靠之前的方法就完全不行，必须换一种新的思路和打法。对于刘伟光来说也是如此，要想进一步推动蚂蚁金融科技，就必须有一套新的打法。首先就要颠覆自己，改变自己近20年的纯粹 IT 思维模式，这本是就是一个巨大的挑战。2018年春节后的一个下午，刘伟光要和公司的 CTO 程立以及副CTO 胡喜讨论headcount（人员招聘）的问题，刘伟光在会议的开始说了一句，“我这里还有些关于业务上的最新的打法可以聊聊”。“那就先说打法吧”，程立打断了刘伟光。程立曾经是支付宝最早的程序员，在蚂蚁金服的十几年中，他经历过 “双11” 的洗礼、“账目三期” 的历练，熟知这家企业在技术上所走的每一步。在2017年杭州云栖 ATEC 大会上，程立首次披露了蚂蚁金服面向未来的技术布局——“BASIC” 战略（“BASIC：Blockchain（区块链）、AI（人工智能）、Security（安全）、IoT（物联网）和 Computing（计算）”）。也正是从那时起，科技 (开放)、普惠和全球化一道，成为了蚂蚁金服的三大核心战略。事实上，蚂蚁金服的科技开放战略早在几年前就有。2015年9月，时任蚂蚁金服总裁的井贤栋就宣布启动互联网推进器计划。随后的几年里，开放战略不断升级，直到成为公司最重要的核心战略之一，这背后有着特殊的时代背景：一是金融系统去IOE、自主可控化的趋势日益明显，二是金融科技的发展体现出深度融合的趋势，银行、新金融机构之间的技术和业务合作正呈现出加速的趋势。在和程立、胡喜的那次谈话中，刘伟光就从赋予金融行业前中后台新的定义、重构未来数字金融这个角度说了自己的想法。他认为，好的科技服务，应该切中用户的真实需求，应该先从服务银行与用户交互最多的移动端发力，重新定义移动端金融的能力，然后走向中台，建立敏捷能力中心，最后再助力银行瘦身后台系统。通过分布式技术平台重构后台核心系统，全新的架构更加强调对业务和产品迭代周期的缩短，增强对新型业务的快速支撑，包括对线上线下业务融合的思考，从而适应中国金融行业发展的趋势。在很多 IT 专业人士眼中，前中后台的提法算不是上什么新词，但是在那个黑板上画出的架构图却是完全不同的定义，但这却是刘伟光和同事在几个月思索后的一些阶段性想法。银行 App 的用户体验，一直是客户诟病的痛点，如果看看手机应用商店下的评论，我们就知道银行在这方面需要做多么大的提升，而这也正是蚂蚁金服能够帮助到银行的地方。无独有偶，蚂蚁的竞争对手腾讯，也在帮商业银行做用户体验大调研，以期从移动端切入用户。讲到最后，程立在白板上写下了自己的愿望，“用技术实现真正的数字金融”。可以说这番谈话开启了后来的很多故事。实现这个业务目标的第一步，是要倾听银行伙伴们在移动端上的真实需求。2018年3月底的一个晚上，在支付宝大厦楼下的一个小饭馆里，刘伟光向同事和盘托出了想从移动端入手的思路。他说，“我们要办一场专注在移动金融的会，请100家银行来，倾听他们的想法，验证我们的思路”。当时刘伟光在喊出100家银行的时候其实心里是很虚的。这些思路和打法到底能否真正得到市场的认可还是个问号。这就是在蚂蚁金融科技开放历程中非常著名的 “511大会”。整个会议的筹备没有用供应商，蚂蚁的人自己来负责会议的通知、接机、组织和所有的会务工作，全员上阵，连 HR 和研发的专家们都在现场做会务支持。通过主动联系和人传人的方式，最后有250家银行报名参加，西子宾馆的大会议室里超过500人云集。在这次会上，刘伟光代表公司将蚂蚁在移动端的服务战略和思路分享给了银行客户，也对蚂蚁未来的前中后台战略做了展望，还请到了银行客户上台发言。当天的会议进行到下午5～6点钟的时候，依然有80%左右的上座率。“我们用蚂蚁的精神办了一场会”，刘伟光说。二、从解决方案入手在加入蚂蚁一年多的多时间里，刘伟光和团队一起拜访了中国数百家家金融机构，每到一地，他都要和当地银行的高管做深入的沟通。在这个过程中，他感受到了银行面向科技、面向移动、面向数字化转型的迫切需求。1、“为什么我们银行做了这么多APP，没有一个app日活量大？”2、“为什么别人是千人千面，我们是千人一面的APP？”3、 “我们花了一个多亿人民币构建一个数据仓库，为什么现在还一张数据报表都跑不出来？”4、“金融科技到底是什么？不是给科技部自用，而是应该给全行所有人包括客户都用的起来的工具才有意义，人人都可以使用大数据系统做 BI，而不是仅限于非常少数的专业人员。“5、“分布式架构就是银行的未来，我们科技部把职业生涯赌在这场改造上，你们蚂蚁金服敢不敢跟我们一起赌？”6、“农村金融是世界性难题，金融科技如果能解决最后一公里的触达，才真正有意义。”7、“中国的城商商业银行如果没有自己的核心客户群，没有核心竞争力的产品，没有差异化竞争，未来的出路在哪里？”这些客户心声给了蚂蚁技术团队非常大的触动，这些问题充满着困惑、焦虑但又极具启发，也促使蚂蚁金服对科技开放的模式进行更深层的思考，传统金融 IT 服务公司讲究的是卖系统、卖软件，鲜少从战略和业务提升的角度入手。然而，今天所有的需求归结到最本质的一点就是，金融科技的开放怎样才能真正给客户带来价值，科技到底能不能和业务的增长产生方程式般的关联度？正如美国柯林斯在其畅销书《从优秀到卓越》一书中所阐述的，技术变革从来不是实现从平庸到伟大的关键因素，在柯林斯眼中，技术是加速器而非驱动企业实现变革的第一推动力。同样，今天金融机构面向数字化的转型，是从之前的 IT 模式，过渡到互联网服务的模式，蚂蚁金服不仅需从自身实践的角度看问题，还要站在客户的视角去找到解决的办法，和他们一起跨越业务和技术之间的鸿沟。数字金融创新，不只是业务导流和线上风控，也不是单一的科技产品应用，而是抵达核心业务系统的转型创新，构建自身的核心数据资产。金融机构需要的是成本低、见效快、可用性高、符合金融级别安全标准、又能够真正带来业务价值的科技输出服务，帮助其进行快速敏捷的产品开发。金融机构的需求就是蚂蚁金服努力的方向。刘伟光和同事在重新梳理产品体系之后，从业务的视角切入，将金融最核心的三个元素抽象出来，推出了 “分布式金融核心套件” 这款新产品。简言之，“分布式金融核心套件” 是一个业务视角入手的产品。金融机构使用之后，既可以针对业务需求进行敏捷开发，快速获取客户，还能将产品工厂、资金交换、核算等金融机构核心业务技术能力封装成业务组件，以支撑各个业务线条的快速调用。蚂蚁金服将很多与此相关的技术能力封装在 “分布式金融核心套件” 之中，与生态 ISV 一起就能够将传统的业务能力叠加进来，从而快速支撑每一项业务的发展，将金融机构过去多个竖井式的核心系统架构改变为适应金融业务和产品快速迭代的分层领域架构，让银行的业务核心能力无处不在。创新与改变，一直是驱动着蚂蚁技术开放团队的源动力。2017年，南京银行引入蚂蚁金服分布式架构 SOFAStack、分布式数据库 Oceanbase 以及大数据平台能力，构建新的互联网核心。同年11月上线互联网金融平台 “鑫云+”，“鑫云+” 一端对接互联网平台的金融需求，另一端对接实际的金融产品和服务，通过使用金融级互联网架构设计模式、敏捷工具和微服务平台，“鑫云+” 从架构设计到上线投产仅用了5个月。上线之后，正好赶上了消费金融的大发展，在截至2018年6月底的最近8个月中，“鑫云+” 平台新客户数达到390万，每日贷款额从1万人民币上升至10亿人民币。“我们用一年时间干了过去十年的业务量”，南京银行信息科技部副总经理李勇感慨的说。三、蚂蚁技术发展历程开放的前提是强大的技术实力。解决实际问题、促进业务发展，一直是蚂蚁金服技术创新的底色。从支付宝最初的担保交易，到后来的快捷支付、余额宝，乃至今天的借呗、花呗、相互宝，蚂蚁金服的发展受益于技术的支撑。在这个过程中，公司内部也形成了独特技术部门组织架构：负责统一架构的事业部，以及各个业务单元里的应用技术事业部，平台技术与应用技术并行不悖，高度融合。为了展示蚂蚁的技术实力，2018年9月20日，杭州云栖大会 ATEC 主论坛现场上演了一场特别的技术秀。蚂蚁金服副CTO 胡喜现场模拟挖断支付宝近一半服务器的光缆。结果只过了26秒，模拟环境中的支付宝就完全恢复了正常。类似的灾备演练在蚂蚁金服内部经常举行，但是在一个公开的场合对外展示却并不容易。“几乎是我们所有人脱了一层皮”，胡喜这样说道，观众看到的是四根线剪掉了，然而由于数据和交易分布在不同的机房，其中牵涉不同的分布式架构，要调动底层数量众多的数据库系统一起协同，难度非常大。现在，蚂蚁金服的机房架构已经做到了 “三地五中心”，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，支付宝的底层技术系统会将故障城市的流量全部切换到运行正常的机房，并且能做到数据保持一致且零丢失。这样的技术架构，让蚂蚁金服的系统持续可用性因此达到了 “6个9”，即便用金融级别的标准来衡量的话，这个水平在全球也是首屈一指的。“这次是演习。而在真实环境下，如果支付宝部署在两个城市的两个机房同时出问题，跑在这两个机房上的支付宝账户恢复正常的速度是分钟级”，胡喜这样说道。胡喜2007年加入支付宝，37岁的他是阿里巴巴集团最年轻的合伙人之一，早些年，胡喜和他的同事，主要面临两个问题：一是让系统容量可以无限增长；二是希望系统持续可用。如果说分布式架构解决了第一个问题的话，那么 “异地多活” 技术的成熟，就意味着第二个问题已经不再是问题。回顾蚂蚁金服技术的发展历程，大致可以分为三个阶段，在第一个阶段，支付宝需要应对 “双十一” 大促海量并发的系统需求，支付宝自身的系统架构从原来的烟囱式改成了分布式，这个阶段支付宝完全是在自我探索；在支付宝掌握了分布式架构技术之后，又将这种技术应用在网商银行等场景，成熟后又通过互联网推进器计划向外输出，成功服务了南京银行等客户；在个案的探索之后，蚂蚁金服将自身的金融科技能力通过 “分布式金融核心套件” 的产品开放出来，将金融机构获取科技服务的门槛大大降低。“打穿打透” 的极致性技术追求，让胡喜和他的同事，将蚂蚁的技术带到了全球 Fintech 领域的最高点。也正是在那次会议上，胡喜宣布，蚂蚁金融云升级成为蚂蚁金融科技并全面开放，目的就是为行业提供完整的数字金融解决方案，而刘伟光就是这个项目的直接负责人。今天，站在金融科技这个赛道上，刘伟光和他的同事深知，任何公司和个人都要适应这个时代的快速转型，只有不停的去挑战自己，永不停歇的思考和不断颠覆自我，才可能保持一点点微小的领先。而这份微小的领先，也只有在开放共享，携手合作中才能焕发真正的能量。蚂蚁金服最希望成为这个赛道上，和众多的金融科技伙伴，始终携手同行的那一个。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...