淘宝

背景商品详情蕴含了十分多的数据，如sku、价格、库存、店铺名称、店铺logo、开店工夫、旺旺、主图、题目等等，很多行业都有须要，比方电商相干行业、淘客、电商软件等都须要用到相干信息，然而官网个别又没有凋谢这些接口，怎么办？ 解决方案当初很多是通过爬虫获取数据，然而基本扛不住大量调用，不稳固，真能稳固获取了也不是个别人有能力去做的，加上淘宝变动频繁，防爬越来越严，技术难度和老本也越来越大，没有能力的也能够找第三方api提供商，方便快捷成本低 参考示例{ "code": 200, "msg": "success", "data": { "item_id": 639989970200, "title": "高尔夫胸包男士静止休闲多功能胸前包男女生腰包斜跨小包机能包潮", "category_id": "122654005", "root_category_id": "50006842", "currency": "CNY", "product_props": [ { "品牌": "GOLF/高尔夫" }, { "质地": "涤纶" }, { "闭合形式": "拉链" }, { "图案": "纯色" }, { "格调": "欧美时尚" }, { "成色": "全新" }, { "风行元素": "车缝线" }, { "色彩分类": "烟雾黑. 雅灰色." }, { "有无夹层": "有" }, { "上市工夫": "2021年秋季" }, { "是否可折叠": "否" }, { "货号": "3G484902" }, { "实用场景": "休闲" }, { "里料材质": "织物" }, { "肩带款式": "单根" }, { "实用对象": "青年" }, { "提拎部件类型": "软把" }, { "箱包外袋品种": "内贴袋" }, { "箱包硬度": "软" }, { "样式": "胸包" }, { "大小": "小" }, { "销售渠道类型": "商场同款(线上线下都销售)" } ], "main_imgs": [ "https://img.alicdn.com/imgextra/i3/3398521191/O1CN01cdCihV1KfWSoJdASs_!!0-item_pic.jpg", "https://img.alicdn.com/imgextra/i1/3398521191/O1CN01yAXdwk1KfWNVDzUUV_!!3398521191.jpg", "https://img.alicdn.com/imgextra/i4/3398521191/O1CN01B06P1Z1KfWNawkLyp_!!3398521191.jpg", "https://img.alicdn.com/imgextra/i4/3398521191/O1CN01NjR8C01KfWNeQi7mX_!!3398521191.jpg", "https://img.alicdn.com/imgextra/i4/3398521191/O1CN018WESll1KfWNcMYYmd_!!3398521191.jpg" ], "video_url": "https://cloud.video.taobao.com/play/u/3398521191/p/2/e/6/t/1/313489603531.mp4", "comment_count": "764", "favorite_count": "2294", "shop_info": { "shop_name": "golf逸君专卖店", "shop_id": "423767709", "shop_url": "//shop.m.taobao.com/shop/shop_index.htm?user_id=3398521191&item_id=639989970200", "shop_rate": [ { "title": "宝贝形容", "type": "desc", "score": "4.9 " }, { "title": "卖家服务", "type": "serv", "score": "4.9 " }, { "title": "物流服务", "type": "post", "score": "4.9 " } ], "all_items_count": "323", "new_items_count": null, "good_rate_percentage": "100.00%", "followers": "3.4万", "is_tmall": true, "is_gold_seller": false, "shop_logo": "//img.alicdn.com/imgextra//67/6a/TB1OOeSa.EIL1JjSZFFSuw5kVXa.jpg", "shop_start_time": "2017-08-21 18:00:37", "seller_id": "3398521191", "wangwang": "https://amos.alicdn.com/getcid.aw?groupid=0&s=1&Kwmw88&charset=utf-8&uid=golf%E9%80%B8%E5%90%9B%E4%B8%93%E5%8D%96%E5%BA%97&site=cntaobao&mebEAA" }, "delivery_info": { "area_from": [ "广东省", "广州市" ], "area_id": "610102", "postage": "0" }, "sku_props": [ { "prop_name": "色彩分类", "pid": "1627207", "values": [ { "name": "烟雾黑.", "vid": "1318628226", "imageUrl": "https://img.alicdn.com/imgextra/i2/3398521191/O1CN01tmkZPF1KfWQMb5zKS_!!3398521191.jpg" }, { "name": "雅灰色.", "vid": "828696142", "imageUrl": "https://img.alicdn.com/imgextra/i3/3398521191/O1CN01cKnlSM1KfWQN9t1EO_!!3398521191.jpg" } ] } ], "skus": [ { "skuid": "4738838588906", "sale_price": "149", "origin_price": "209.00", "stock": "200", "props_ids": "1627207:1318628226", "sub_price": "129", "sub_price_type": "pre-sale balance" }, { "skuid": "4738838588907", "sale_price": "149", "origin_price": "209.00", "stock": "85", "props_ids": "1627207:828696142", "sub_price": "129", "sub_price_type": "pre-sale balance" } ], "promotions": [ { "content": "淘金币可抵4.47元", "sub_content": "淘金币可抵4.47元", "start_time": "", "end_time": "", "type": "default" }, { "content": "满149减20", "sub_content": "满149减20", "start_time": "2022-04-16 00:00:00", "end_time": "2022-04-23 19:59:59", "type": "default" }, { "content": "满149元,省20元", "sub_content": "焕新价减20", "start_time": "2022-04-16 00:00", "end_time": "2022-04-23 19:59", "type": "3" } ], "buy_enable": true, "cart_enable": true }}

作者：千之 上篇回顾：淘宝小部件：全新的凋谢卡片技术！ 2021 双十一，淘宝全新的凋谢状态「小部件」大促中首次亮相，并且撑持凋谢业务初步规模化；说起小部件，咱们还是先回顾一下淘宝小程序凋谢的前世今生。 小程序凋谢的前世今生从页面级凋谢到模块级凋谢淘宝凋谢业务的实质，就是通过联结三方凋谢生态的力量，帮忙商家在淘內实现更好的商业经营行为，提供优良的消费者体验。面对商家凋谢定制水平高、经营数据协同性强、更高效经营链路的谋求下，咱们对凋谢技术的摸索永无止境。 过来咱们提供了小程序的能力，突破了 H5 页面之间的边界和割裂，商家能够深度经营本身的消费者；在这个过程中，咱们借力了小程序成熟的业界生态和欠缺的工程基建，通过独立页面的状态来撑持了咱们本身业务的倒退，譬如购物小程序、淘积木广告等等。 起初，咱们和店铺团队单干，通过基于小程序环境下的插件凋谢，帮忙店铺引入了 100+ ISV和数千家设计师，为上万的品牌和商家提供了差异化营销能力。这套技术人造是以小程序插件为外围的技术计划，也是小程序环境+小程序规范；将商家自经营主阵地店铺小程序插件化，并对旺铺平台降级，使店铺成为商家可高度模块化定制、个性化经营、差异化承接公域的外围经营阵地。 再起初，咱们发现小程序技术尽管带来了业务资源的对立和利用率的微小晋升，但小程序独立状态的实质让咱们的谋求受限。小程序独立的页面状态和消费者流量承接效率之间人造会存在博弈，这里包含用户点击会存在跳失率的起因，也包含整个消费者拜访门路过长的起因，也有短少消费者前台心智的起因。 种种原因下，基于在小程序多年的技术积攒和积淀，咱们启动了小部件凋谢我的项目。 小部件实质上是一个凋谢的模块全域通投技术， 通过小部件，咱们能够把业务投放在各大非小程序环境的业务场景中，譬如详情、搜寻、首猜、订阅等等，当然也能够在店铺中投放。 小部件和小程序的关系小程序的姊妹状态小部件和小程序的关系是什么？ 一言以概之，小部件是小程序的姊妹状态。 过来，咱们基于在小程序多年的技术积攒和积淀，咱们积淀了小程序平台，作为小程序/小程序的外围零碎平台，也是小程序零碎的基石，提供着最根底稳固的运行服务和数据能力； 在开发者应用的凋谢能力的背地，咱们还有着诸多能力的根底平台，开放平台，提供了大量可应用可利用的根底能力；在小程序中咱们积攒了成熟的开发者工具体系，包含 IDE、构建器等等这些一站式的工程工具；此外，咱们在横向自研了一个高效又轻量的 Weex2.0 渲染内核，通过渲染内核的降级和打磨，咱们使得 Weex2.0 成为小部件渲染的外围根底；另外还有咱们有着在小程序下积攒的一批富裕淘宝特色的 API 和根底 API 能力，这些 API 能够无缝在小部件下被咱们的开发者所应用；再者，咱们领有和小程序同构的业务容器，稳固隔离的业务容器使得咱们能够高效推动小部件相干的业务在平安的水位下运行。 除了这些平台本身的根底能力，咱们还有来自广告公司、品牌的陈腐创意，通过创意的组合和生态的单干，咱们为业务供应养料；另外还有来自开源社区的输出，与之配套的强壮工程体系。 站在这些伟人的肩膀上，通过这些生产因素的组合，咱们在小程序之外孵化了一个新的凋谢状态：小部件。 小部件通过规范、能力、场景的三层凋谢，开释了新一轮技术红利；咱们持续标准化了凋谢能力的应用和残缺的技术接入流程，通过新的场景凋谢晋升了生态的创收空间。 在业务侧，咱们心愿通过小部件能够撬动商家的经营心智，并最终晋升商家的经营链路成果，为商家的经营效果所买单负责。 小部件是什么淘宝凋谢的新形态，卡片级凋谢计划那么，回到小部件上来，小部件是什么？ 小部件是淘宝凋谢的新形态，是咱们模块级的凋谢解决方案。 小部件生态里的开发者和设计师们能够通过咱们的前台业务（LiveCard/前置卡片）来进入小部件的生产流程，通过咱们的凋谢工具譬如淘宝开发者工具或者游戏引擎IDE来生产本身的物料，再通过咱们的云函数/云利用来连贯开发者本身的云，实现业务逻辑的研发闭环。 小部件的开发者生产完物料之后，会通过咱们简单的投放零碎来做投放；这里平台会有一些规定的检测和束缚机制来保障流通的效率，针对不同的场景下，开发者能够开发不同的小部件来适配场景和适应场景的业务规定，此外，针对投放侧还有一些配置数据的关系存储，最初这些业务数据会以报表的状态展示在商家前台；不便商家晓得自家模块的正题状况，包含消费者点击PV、UV这些，还有疏导成交数据等等。 投放操作实现后，小部件会在前台业务场景实现渲染，这里的技术细节会非常复杂。因为在不同的场景下会波及多个场景本身的容器，这里包含PHA、Weex｜DX、小程序等等，所以咱们须要通过一些形式间接嵌入在前台场景中。而后运行时会动静拉取对应的JS包再加以执行，这个逻辑也会非常复杂，在小部件容器层面，咱们会对立元信息、根底库能力、生命周期等等能力；局部能力和小程序容器是间接专用的。最初 JS 代码会传递到小部件的内核，也就是 Weex2.0 内核中，Weex2.0 内核中包含了咱们自研的脚本引擎、图形引擎还有渲染引擎。内核次要负责执行逻辑和提供渲染实现，通过Weex2.0 提供的跨平台渲染一致性能力，咱们在 iOS/Android 上能够实现简直一摸一样的款式能力和动画能力，也能保障开发者的代码能够无缝渲染两端。 最初是咱们的撑持平台，通过开放平台、小程序平台、小二经营平台的横向撑持和上述生产侧、投放侧、运行侧的配合，咱们能够面向私域场景输送小部件的供应。这里包含店铺、详情、搜寻、首猜、订阅等等；面向这些场景下，咱们能够提供最上方的卡片供应，还有商品卡片、互动卡片、小程序卡片、内容卡片、权利卡片、3D卡片等等。 对于小部件的具体技术介绍，能够参看笔者之前的文章：淘宝小部件：全新的凋谢卡片技术！ 小部件能帮忙业务解决什么问题那回到一个业务命题上来，小部件能够帮忙业务解决什么问题？ 咱们拿店铺举例。 首先回顾一下店铺凋谢业务的往年策略，店铺往年从新做了凋谢业务的策略降级，次要是三个关键词。 首先是「表白模式降级」，店铺模块降级为 LiveCard，并通过多个 LiveCard 组合为 MiniShop、每日好店等；第二个关键词是「凋谢模式降级」，通过视觉凋谢、性能凋谢、利用凋谢的三个纬度，能够以卡片组合的形式来作为业务的前台表白；第三个关键词是「内容供应降级」，过来店铺里的模块大多数是商品货架卡片为主，内容化的模块绝对较少，通过内容供应的降级，利用小部件丰盛的开发者生态和弱小的互动前置能力，咱们能够将互动游戏间接前置在店铺模块中。 刚刚好，小部件的技术体系完满符合了店铺业务降级的思路。 开发者开发的一个 LiveCard 模块在店铺装修后，能够流通到详情页，并且在详情页的体验和店铺首页的体验是截然不同的。当然，这外面详情只是其中一个场景，店铺通过 LiveCard 能够从单纯的货架类卡片拓展到单品、举荐、权利、互动、内容、小程序等多类型卡片，丰盛了各个场景的卡片供应，满足了商家多元化的经营诉求，最大限度得开释商家的生产力。 店铺应用小部件能够实现商家价值与平台价值的对立，业务能够通过小部件来积淀本身的商家资产，并作结构化积淀和利用，商家能够在店铺内通过小部件获取体验一致性和更大的凋谢空间作自家店铺的深度定制，对于咱们的生态来说，生态里的开发者能够获取多场景、多赛道的创收空间，帮忙开发者能够在更多的业务场景取得商业价值。 ...

随着淘宝的衰亡，一个围绕淘宝店铺衍生进去的店铺经营行业就由此诞生了。曾几何时，咱们开淘宝店时并没有什么所谓的淘宝店铺经营这么一个名词。起初，淘宝网店只是简略的将线下的产品搬到线上发售的模式，属于粗放型模式，而明天的淘宝已正值盛年，领有本人残缺生态体系，明天的咱们只有将淘宝店铺经营技巧使用到极致，才有可能在淘宝千万卖家中胜利解围。 闲话少说，干货呈上！ 上面给大家分享大神级经营日常工作内容是怎么样 一、经营工作打算 1.店铺的年度指标销售额 2.客单价+转化率（保持稳定+增长） 3.12个月度销售打算拆分到访客数 4.每月销售预估 5.每月投入产出估算 二、经营工作安顿 1.行业、类目、子类目、竞争对手的剖析 2.布局主推产品，做好用户精准标签 3.优化页面，进步转化率 4.正当利用收费流动资源（保障不是垃圾流量） 5.加入第三方的流动，布局多流量入口 6.直通车、钻展、淘宝客的使用 三、每日数据统计，店铺数据分析 1.日均PV\UV 2.拍下总件数、订单数、金额 3.成交用户数、回头客数 4.商品珍藏量、珍藏率 5.全店转化率、行业转化率 四、日常团队工作、协调 1.每日商品点击率抉择适合的商品替换 2.店铺整体页面优化替换 3.流动群信息及时关注，依据销售数据实时调整 五、制订店铺推广打算 1.主推产品：确定产品价格，产品须要，依据产品参数制订SKU 2.品牌定位：依据产品线，进行产品卖点研发及品牌宣传 3.首页排版：综合市场剖析，设计品牌首页，突出品牌特点 4.流动策动：依据所选爆款制订做出大力度的流动策动 5.爆款详情页设计：突出产品痛点和卖点 6.关联营销：制作2-4个的关联营销 7.会员营销：设置会员VIP优惠折扣并短信告诉 六、经营工具 生意顾问：官网经营工具，淘宝数据化经营工具，帮忙卖家通过大数据进行选品与流量布局。 店铺宝：能够设置满减、满折、满包邮等权利（这些促销工具，官网后盾很多，能够抉择对应的促销工具，在这里就不费口水了）。 魔镜：对直通车、搜寻排名、洞察同行网店流量起源等有肯定的参考价值。 店侦探：一款能全面跟踪天猫淘宝店铺的经营数据工具,提供爆款关注,题目改变跟踪,改价跟踪,淘宝流动跟踪、天然搜寻排名跟踪,直通车关键词排名跟踪等性能。 店查查：提供淘宝数据统计、店铺关注、宝贝价格关注、直通车选词、题目优化、销售数据分析等网络服务。 M1短链接平台：专业级收费在线短链接生成工具，将店铺宝贝链接转成短链接，便可在各大店铺营销引流，不会被屏蔽，同时登录后盾可实时获取用户行为数据，实时掌控营销成果。

我常常接触到一些年利润百万的大卖家们，总能听他们说产品又爆了，月销万单，一天就卖出去几十万……，咱们本人这两年也始终在做新店，从0做到营业额五千万的就有两家，年销超过一个亿。咱们打造了一个又一个的爆款，利润都很高，为什么到明天咱们还能做到业绩这么好？ 一、明天就分享给大家一些心得，也会剖析很多人店铺做失败的起因 1、找准细分人群 在卖这个产品之前，提前去剖析定位产品它的精准用户是哪个人群，剖析维度包含：年龄、性别、爱好、会搜寻的关键词等等，肯定要做好用户画像的剖析，确定所卖的产品就是针对这类人群的，而不是针对绝大部分人。 2、做差异化 剖析完本人就须要接着剖析同行、剖析他们的产品特点。比方，咱们卖键盘，重点不是去剖析其余的键盘，而是要去对标和咱们用户群定位一样的键盘。在主图、详情页、卖点以及定价等方面比照竞品要去进一步的优化，作出咱们本人的劣势。 3、抓住流量去经营 既然找准了精准用户，就要从一开始就针对性地去抢流量，占据这个细分人群的流量，而不是去抢整个市场的流量，那些都是不精准的。咱们外围用户的流量以及竞品的流量，都是十分精准的，才是咱们要去抓住的。 4、长于复制细分畛域的爆款 当咱们做胜利一个爆款，肯定会剖析出咱们胜利的点是什么，从而持续疾速上架其余的产品。退出第一个爆款外围用户是男性，那第二个就能够针对女性，第三个针对老人，第四第五个减少产品性能，这样一直去复制，就能够领有四五个爆款产品，抢到了更多的细分市场和流量。所以，咱们做胜利的几家店流量都十分大，甚至大部分都是收费流量，因为这才合乎平台的流量分配原则。 二、这套办法胜利的逻辑在哪 咱们都晓得做好了点击率和转化率，能力晋升流量。咱们从开店筹备就剖析分明了咱们的产品要卖给谁，在此基础上再去做好优化，最终达到一个流量的爆点，当你找准你本人的外围用户，平台才会调配更多的精准用户给你。 三、为什么很多人的店铺会失败？ 十分多的卖家，甚至包含已经赚到不少钱的一些卖家，都不懂得怎么去做细分和差异化，也就导致了引来的流量品质极差，转化率太低，流量也越来越少。而这些失败的卖家，比拟喜爱说平台不行，不是本人的问题，其实失败的次要起因在于本人。实际上平台每年的玩法规定都在一直变动，咱们须要一直地测试，总结规定才行。 往年想要做好淘宝店铺的卖家，肯定要抓住这四点：细分人群、差异化、流量经营、爆款复制！！！ 情谊举荐：最初，给大家举荐一款收费引流利器——M1短链接生成器[网站：M1.FIT]，能够把咱们店铺的宝贝链接转成短链接，转成短链接之后，就能够在各大平台进行分享引流，不会被屏蔽，同时，登录后盾还能查看短链接的实时用户统计数据，能够分明理解引流状况，比拟好用！

背景在电商行业还是销量为王，因而在很多相干行业，比方数据分析行业都须要用到相干的商品销量信息，然而官网个别又没有凋谢这些接口，怎么办？ 解决方案当初很多是通过爬虫获取数据，然而基本扛不住大量调用，不稳固，真能稳固获取了也不是个别人有能力去做的，加上淘宝变动频繁，防爬越来越严，技术难度和老本也越来越大，没有能力的也能够找第三方api提供商，方便快捷成本低 参考示例{ "code": 200, "msg": "success", "data": { "confirmed_count": "28", "month_sold_count": "35" }}

背景在很多行业，比方淘客、商品采集、登载、数据分析行业都须要用到相干的商品接口，然而官网个别又没有凋谢这些接口，怎么办？ 解决方案js逆向爬虫倒是很简略，然而基本扛不住大量调用，不稳固，目前支流的计划都是逆向APP获取数据，然而这个不是个别人又能力去做的，加上淘宝变动频繁，防爬越来越严，技术难度和老本也越来越大，没有能力的也能够找第三方api提供商 参考示例{ "code": 200, "msg": "success", "data": { "item_id": 637336124117, "title": "膳魔师真保温杯进口保温水杯家用细微杯子便携保温杯JNI-401母婴", "category_id": "121450007", "root_category_id": "50014812", "currency": "CNY", "product_props": [ { "key": "产地", "value": "马来西亚" }, { "key": "品牌", "value": "THERMOS/膳魔师" }, { "key": "货号", "value": "JNI-401-1" }, { "key": "材质", "value": "不锈钢" }, { "key": "色彩分类", "value": "红色-MBE 灰色-MGY" }, { "key": "实用年龄", "value": "12岁 4岁 14岁以上 6岁 8岁" }, { "key": "容量", "value": "400mL" }, { "key": "是否带柄", "value": "否" } ], "main_imgs": [ "https://img.alicdn.com/imgextra/i1/2392773550/O1CN011fFFv11c5wkvEN9XO_!!0-item_pic.jpg", "https://img.alicdn.com/imgextra/i2/2392773550/O1CN01T1Zpn11c5wgsPFOnw_!!2392773550.jpg", "https://img.alicdn.com/imgextra/i3/2392773550/O1CN01rFXUDT1c5wgzhxNef_!!2392773550.jpg", "https://img.alicdn.com/imgextra/i4/2392773550/O1CN01F4RAIT1c5wgyZxfiu_!!2392773550.jpg", "https://img.alicdn.com/imgextra/i4/2392773550/O1CN01zE04E91c5wdjO0v8C_!!2392773550.jpg" ], "video_url": "", "comment_count": null, "shop_info": { "shop_name": "THERMOS膳魔师海内旗舰店", "shop_id": "116191012", "shop_url": null, "shop_rate": [ { "title": "宝贝形容", "type": "desc", "score": "4.8 " }, { "title": "卖家服务", "type": "serv", "score": "4.8 " }, { "title": "物流服务", "type": "post", "score": "4.8 " } ], "good_rate_percentage": null, "followers": null, "is_tmall": true, "is_gold_seller": false, "shop_logo": "//img.alicdn.com/imgextra//f0/81/TB1Op4LHXXXXXaXXFXXSutbFXXX.jpg", "shop_start_time": null, "seller_id": "2392773550", "wangwang": "" }, "delivery_info": { "area_from": [ "香港" ], "area_id": "1", "postage": "0" }, "sku_props": [ { "prop_name": "色彩分类", "pid": "1627207", "values": [ { "name": "红色-MBE", "vid": "60092", "imageUrl": "https:https://gw.alicdn.com/bao/uploaded/i3/2392773550/O1CN019mPKe61c5wipzwYyA_!!2392773550.jpg" }, { "name": "灰色-MGY", "vid": "3232480", "imageUrl": "https:https://gw.alicdn.com/bao/uploaded/i4/2392773550/O1CN010hlSxz1c5winLXo7H_!!2392773550.jpg" } ] } ], "skus": [ { "skuid": "4576934505784", "sale_price": "229", "origin_price": null, "stock": "285", "props_ids": "1627207:60092", "sub_price": null, "sub_price_type": null, "sub_price_cart": "99", "sub_price_cart_type": "活动期券后" }, { "skuid": "4576934505785", "sale_price": "229", "origin_price": null, "stock": "338", "props_ids": "1627207:3232480", "sub_price": null, "sub_price_type": null, "sub_price_cart": "99", "sub_price_cart_type": "活动期券后" } ], "promotions": [ { "content": "跨店每200减20", "sub_content": "跨店每200减20", "start_time": "2021-12-12 00:00:00", "end_time": "2021-12-14 23:59:59", "type": "default" }, { "content": "淘金币抵3%", "sub_content": "淘金币抵3%", "start_time": null, "end_time": null, "type": "default" }, { "content": "商品券满189减90", "sub_content": "满189减90", "start_time": "2021-12-12 00:00:00", "end_time": "2021-12-14 23:59:59", "type": "default" } ] }}

淘宝作为电商的代名词，始终被大家所推崇，曾几何时，一直演出着“屌丝逆袭”的神话，一个无门槛、不看出身的C2C平台，人人都能够参加其中，分享时代红利！再过来，只有你有产品，你有渠道，开家淘宝店铺基本上就能够有不错的支出，不过这样的红利时代曾经一去不复返。现在，做淘宝一看资金、二看技术的年代，没资金又没技术的小卖家基本上曾经“辞别”了淘宝。 淘宝中小卖家的前途在哪里 淘宝曾经是B2C的成熟期，搜寻框下满屏的天猫店就不难看出，C店想要与B店竞争基本上是不可能，权重不一样，流量也不一样！淘宝要的就是C店卖家源源不断的入驻B店的成果，中小卖家注定不可能有太多的流量，如须打爆新品得须要另辟蹊径。 站外流量获取已成为淘宝中小卖家的制胜要害 站外流量次要以抖音、快手以及小红书为主的站外C端流量平台，咱们能够依据本人行业的不同，抉择不同的表现形式，例如：购物心得分享型，选购领导型，展现型，好物举荐型等等形式，获取流量的形式多种多样，大家能够自由发挥，像以短视频为次要阵地的抖音阵地咱们就应该依据本身行业剖析用户爱好，而后去抉择一个喜好点作为抖音短视频的内容定位。 对于中小卖家新品破零很要害，新品怎么能力破零、 中小卖家自身本身权重就小，上新是一个很要害的流量获取形式，然而新品上架后必须在24h内破零，能力进一步取得更多淘宝流量，所以说，中小卖家新品破零是打造爆款的第一步！ 24h破零办法： 1、老客户破零； 2、淘宝客破零； 3、站外折扣、赠送礼品或0元购物破零； 4、亲戚朋友破零； 5、SD破零（这个办法不举荐） 对于破零这方面，咱们肯定要留神，每一个店铺、每一款产品都有本人的专属标签，这点不能弄乱了！如果用SD的话，很容易造成标签凌乱，咱们最好针对性抉择同一类型标签的用户破零。 新品破零之后如何打造爆款 新品破零之后，咱们须要在每天有一个持续性增长，后期增长的幅度不能太大，要做好销量与DSR，前面再适当地开下车，同时，咱们能够设置好配送的一些小样礼品，这样不仅能把流量做下来也能够把转化率做上来，一旦产品流量起来，单个产品的权重也会一直减少。 爆款打造具体方法介绍: 1、关键词卡位，某些关键词在天然搜寻中首页靠前的地位必须要有展现； 2、开明淘宝客高佣金，依据销量来设置佣金多少，后期高佣金； 3、开直通车（钻展临时就不用了），为新品打爆提供火力； 4、报名平台的一些流动； 5、筛选时段，进行直播； 6、站外在特定平台、社群等获取流量，可提前潜伏、引爆； 7、店铺流动、搭配离谱、满减、满送等要提前做好； 8、DSR肯定要做好； *新品打爆之前，要一直测试宝贝是否具备打爆的可能性，看看市场反馈如何。 新品打爆不仅仅是依附站内流量来反对，咱们在站外也有很多形式能够去做，也有很多的营销策略能够去操作，具体这些也是仁者见仁的事了。 另外，咱们个别在站外推广，无非是短视频平台、挪动社交媒介、微信群等等，咱们要在某些平台推送，难免会碰到一些问题，例如分享的链接被屏蔽或垃圾链揭示等等，会让咱们的站外引流成果大打折扣，在这里就须要提到一个比拟有用，可躲避被屏蔽危险的工具M1短链接，这是个收费的在线短链接生成器，只有把咱们的店铺网址转换成短链接，不仅链接简短不占字数，同时，还能统计用户行为数据，从我的角度来看，比拟适宜我，在这里也举荐给大家，心愿咱们淘宝卖家款款新品都能打爆，日进斗金！！！ 【申明】原创内容，转载请注明出处M1.FIT,勿删改本文内容！

淘宝成立至今已有十八年之久，十八岁曾经逐步走向了成年，围绕淘宝而建设起来的生态也未然造成，淘宝生态已进入成熟发展期，也曾经从过来的蓝海倒退成现在的红海市场。通过往年双十一能够发现，平台与商家对双十一的激情仿佛有所降温，这背地也是对电商红海到来的无奈！ 一、淘宝等电商平台，面临哪些挑战 1、通过近20年的倒退，卖家趋于饱和 2、站内流量竞争强烈，面临口多食寡的场面 3、同业竞争导致分流显著 4、社交电商与短视频电商的衰亡对传统电商带来微小的挑战 5、直播带货的虹吸效应，分流显著 6、商家多元化倒退，站外布局，进一步弱化了平台的影响力 十年前，说到做电商，咱们就会想到淘宝，现如今，咱们说道电商脑海里会呈现淘宝、天猫、京东、拼多多、抖音、快手等等泛滥的平台，而当咱们说到这些平台，第一反馈会感觉淘宝、天猫、京东竞争压力太大，拼多多、抖音、快手感觉机会面更大，新老交替难免会对淘宝等传统电商带来阵痛，咱们电商卖家如何求变才是至关重要的“制胜”之路！ 二、淘宝中小卖家如何打造爆款 在这里，想一些店铺的基本面就不做介绍，这些须要配合平台要求的咱们要第一工夫按平台要求去满足，在这里我只说一些宝贝打爆办法，尤其是针对中小卖家！ 1、店铺定位要做好，专一小而美，专精特畛域 2、通过生意顾问，找到竞争力低的细分畛域 3、新品破零，24h之内实现新品破零 4、为宝贝打上专属标签，店铺与宝贝标签不能乱 5、宝贝流量的持续增长 6、宝贝DSR保护，做好风控 7、通过站外布局流量入口，引流站外流量 *站外推广难免会遇到各大平台屏蔽、封杀链接的状况，大家能够去找个在线短链接生成器生成个短链接，就能够在各大平台分享链接。如果没用过的能够用M1短链接平台生成短链，不仅能够防屏蔽还能实时统计用户行为数据，我目前也在用这个，举荐给大家。 淘宝中小卖家如果想要疾速打造爆款，从千军万马中突出重围，就必须学会从“店铺定位-产品抉择-如何导流-如何打爆”整个环节。淘宝、京东这些平台的大卖家都曾经踊跃布局站外流量，咱们中小卖家也必须紧跟脚步，踊跃布局站外流量，一直为站内店铺做好赋能，跟上时代步调，才不至于落伍。 电商倒退曾经进入多元化时代，只有顺应时代倒退能力走得更远、做得更好！ 【申明】原创内容，转载请注明出处M1.FIT！

简介： 随着 Serverless 在业界各云平台落地，阿里外部 Serverless 研发平台、各种研发模式也在业务中逐渐落地，热火朝天。在此契机下，淘系团队启动了轻店 Serverless 研发模式降级战斗，基于阿里团体底层设施建设、下层技术体系，解决在淘系轻店业务场景下碰到的系列问题，并借此推动现有前后端合作模式转变。 一、前言 随着 Serverless 在业界各云平台落地，阿里外部 Serverless 研发平台、各种研发模式也在业务中逐渐落地，热火朝天。在此契机下，淘系团队启动了轻店 Serverless 研发模式降级战斗，基于阿里团体底层设施建设、下层技术体系，解决在淘系轻店业务场景下碰到的系列问题，并借此推动现有前后端合作模式转变。 二、背景 轻店业务是淘系新型业务，目前处于摸索试错阶段，如何能以较低人力老本配合业务疾速试错，是团队以后须要思考的问题。Serverless 重要的特点之一“only focus your business”。因而，拥抱 Serverless，轻店业务势在必行。本篇次要介绍，Serverless 技术在轻店前端团队如何落地，以及如何推动轻店研发模式降级，晋升研发效率。在此基础上，同时摸索前端职能转变成为利用开发的可能性。 三、研发模式降级 本文首先调研阿里团体内外 Serverless 现状，联合本身业务特点做技术选型；随后在轻店域内进行业务落地，在落地过程中逐渐落实以下能力：以 sidecar&bottle 作为底层撑持，以一体化研发模式联合公共服务层、原子能力层、根底 SDK 来晋升研发效率；最初通过轻店规范研发链路来保障业务稳定性；最终造成轻店 FaaS 体系，初步实现研发模式提效降级。 1. 技术现状 阿里团体各 BU 过来一年里在 Serverless 畛域做了很多工作，次要集中在根底建设、研发模式、逻辑编排、稳定性建设、以及将 faas 链路买通并落地到 B 侧和 C 侧业务场景，如下图所示。各业务依赖的 Serverless 平台集中在 C 平台 / F 平台（PS：阿里外部 Serverless 平台）。 2. 技术选型 以后阿里团体 Serverless 平台和 midway-faas 团队深度单干，定制了基于阿拉丁 FaaS 计划，依靠袋鼠为业务网关，承载申请散发的职责，并且有容灾、兜底等通用能力。袋鼠以天马体系（PS：指以对立模块标准为根底的搭建体系）为根底底座，然而轻店业务底层依赖装修体系。因而，咱们须要从新选型实现基于轻店场景的 faas 解决方案。除此之外，轻店业务外围依赖各种中台服务。这些中台服务大部分是以富客户端（PS：指集成了本地能力的二方包）模式提供，如何在 nodeFaaS 体系中应用富客户端，是咱们技术计划须要思考的重点。上面是 C 平台计划（PS：阿里外部的 Serverless 平台） 和 G 平台计划（PS：阿里外部的 Serverless 平台）的链路比照图。 ...

技术编辑：宗恩丨发自 思否编辑部 SegmentFault 思否报道丨公众号：SegmentFault 最新消息，「淘宝台湾」被断定为中资企业，台当局裁罚41万新台币（约合9.7万元人民币），并限期6个月内撤资或改过。淘宝台湾示意，淘宝台湾由英商克雷达台湾分公司经营，克雷达股权来自不同国家的外资基金投资，投资比率皆依循台湾法律。 台当局给出的理由：淘宝台湾虽由英商克雷达分公司经营，但克雷达可被阿里巴巴团体本质管制，从而断定「淘宝台湾」为中资。 英商克雷达投资有限公司于2019年7月4日，以10万新台币（约合2.4万人民币元）在台设立分公司，而后于10月间减少营运资金至2010万新台币（约合473万元人民币），并以「淘宝台湾」名义经营网购平台。 阿里巴巴团体透过新加坡子公司持有英商克雷达28.77%股权，未超过30%，合乎现行「大陆地区人民来台投资许可方法」，但依法令或契约约定，阿里巴巴可操控英商克雷达的营运方针，认定对其具备控制能力。 台当局较早时以法令未凋谢大陆企业网络串流媒体（OTT）到台，以及恐在文化等内容上影响台外部，公布「在台湾地区从事商业行为禁止事项项目表」，也就是俗称的《爱奇艺条款》，将从9月3日起禁止代理或经销大陆网络串流媒体的企业在台营运。 直白点说，这份通告就是针对爱奇艺和腾讯的。因为在布告中，台当局就间接点明：「为避免大陆地区OTT-TV（如爱奇艺、腾讯等）通过代理或经销等曲折形式在台湾『非法』经营」。 「连大陆电视剧平台都怕吗？」，台湾媒称正当的管制伎俩应是激励爱奇艺在台湾注销、注册，而不是全面禁绝。在媒体汇流的趋势下，民众通过网络看影音产品已是势不可挡的潮流，当局此时立法管制，「非然而螳臂当车，更是时空错乱」。 台湾网友评估，台当局「锁台」，是「井底蛙」。还有网友说，台当局整淘宝，后果只会「整死」台湾几万家中小企业家和卖家。更有网友猜想腾讯旗下的「虾皮」恐怕是下一个被禁用的。「虾皮」尽管设点在新加坡，但母公司为腾讯，持有39.7%股权。

本文由手机淘宝技术团队原创分享，吴志华（天施）、洪海（孤星）、陈虓将（仲升）等专家参加了本文创作，首次发表于公众号“淘系技术”，收录整顿时有订正和改变。 1、引言挪动端网络的优化是超级APP们永恒的话题，而对于无线电商来说这更为重要，因为网络申请体验跟用户的购买行为非亲非故。 手机淘宝从过来的HTTP API网关，到起初扛住双十一战场次要流量的自研高性能、全双工、平安的ACCS（阿里云通道服务），无论是基础架构的演进、网络调优、协定的优化、异地多活、网络调度上，都有不少贵重的教训与大家分享，本文借此机会总结了整个技术演进过程。 * 浏览对象：本文属于挪动端网络优化的深水区总结性文章，适宜有肯定挪动端网络应用教训的开发者浏览（尤其对挪动弱网有肯定理解的），初学者如果没有相干常识积攒的话，能够简略理解无需深刻。如果你对挪动弱网很有趣味，能够进一步浏览本文开端“附录”局部的举荐文章。 本文已同步公布于“即时通讯技术圈”公众号，欢送关注： ▲ 本文在公众号上的链接是：点此进入，原文链接是：http://www.52im.net/thread-3110-1-1.html 2、相干文章《Netty干货分享：京东京麦的生产级TCP网关技术实际总结》《知乎技术分享：知乎千万级并发的高性能长连贯网关技术实际》《手机淘宝音讯推送零碎的架构与实际(音频+PPT) [附件下载]》3、技术背景回忆挪动电商在双十一业务开始衰亡的时候，过后双十一当天挪动成交243亿占整体571亿的42.6%。 业务高速倒退心愿更多被动推送去触达用户，一些新的玩法和互动模式，须要连贯买家与买家、买家与卖家、买家与达人，因为没有无效的通道能力，业务采取的是不停去轮询服务器，一来对服务器造成不必要的压力，二来对于用户手机的电量流量也是极大的节约，要害在双十五这种大促的状况下，不必要的申请过大甚至会导致后端集群限流，从而影响到用户体验。 信息流传状态的变动的背地是挪动化带来新的技术特色导致的后果。挪动电商畛域，手机淘宝始终是先行者。挪动电商从最后的复制WEB的业务状态到挪动个性不断涌现，更多的互动模式的呈现，向社交化、娱乐化一直迈进的明天，一个单纯的商品的陈列架模式曾经不能满足业务的需要。 业务上须要实时的触达用户，充分发挥挪动的个性，将生产工夫的碎片利用起来，事实也证实了用户的生产工夫随着挪动化的过程一直发生变化，逐渐散布到全天的碎片工夫中。同时货架状态也在向社区化、娱乐化的方向倒退，这些都对网络层连贯用户有了更高的要求。更多的媒体状态和展现形式，对网络层提出了更多元的要求。 大家能够关注到手机淘宝内的音讯盒子这些产品都是业务求变的体现，业务的变动倒逼技术的后退。 4、挪动网络环境的挑战性始终都存在挪动网络的速度轻易3g、4g、5g的遍及，速度有很大晋升，但网络环境的多样性和差异性使挪动网络的环境更加简单，在过来双十一前还常遇到一些挪动网络劫持的事件。网络劫持这块问题的排查效率很低，须要找到用户、复现现场，甚至找网工、运营商配合排查，一查就是几天过来。 同时在咱们的舆情反馈上总是看到用户在说“某个页面加载中、页面打不开、申请很慢、关上某个性能很慢”，面对这些问题过来咱们是没有太好的方法，只能猫抓耗子一桩桩去排雷很被动。很多网络的问题是偶现的，一旦错过当初就无从查起。 诸如此类的问题，背地的起因很多： 1）运营商问题；2）机房部署起因；3）客户端SDK Bug；4）弱网和网络抖动；5）DNS劫持和数据篡改。在PC时代，咱们拜访网站的接入条件是绝对恒定的，所以在开发时很少思考网络对用户体验的影响。然而挪动APP则不然，尤其是在国内，根底的挪动网络环境还不算太好，而且咱们有很多用户的拜访是产生在地铁、公交车这样的挪动环境下，挪动基站的频繁切换进一步减少了网络的不稳固。从手机淘宝的数据能够看出，咱们每天沉闷用户中有不少来自于弱网环境。如果端到云的连贯不稳固、高延时，那么所有的用户体验都无从谈起。 根底网络的效率就像一辆列车，时延是火车的速度(启动工夫)，而带宽就像火车的车厢装载量，整个传输的物理链路就像火车的铁轨。目前事实条件下的挪动网络条件非常复杂，咱们的指标很简略，就是想让所有用户都能在手机淘宝取得晦涩的体验。 上面这张图，可能让大家更加直观的理解国内的挪动网络环境。形容了从用户到IDC的端到端的路由状况，不仅数据传输耗时长且丢包率高，同时安全性也是相当蹩脚的，DNS劫持、内容劫持在中国就是粗茶淡饭。 因而，咱们在改善网络通道上有很多的事件能够去做，去摸索冲破运营商根底网络的限度，力争为用户发明极致的购物体验。 挪动端的DNS问题相当广泛，能够详读以下专题文章： 《全面理解挪动端DNS域名劫持等杂症：原理、本源、HttpDNS解决方案等》《美图App的挪动端DNS优化实际：HTTPS申请耗时减小近半》《百度APP挪动端网络深度优化实际分享(一)：DNS优化篇》《挪动端网络优化之HTTP申请的DNS优化》5、整体技术架构为了满足挪动电商业务高速倒退的需要，咱们决定打造一个世界级的网络接入服务，构建一个无线网络下”水、电、煤“ 一样的基础设施。 这样一个基础设施须要做到的四个指标： 1）全双工；2）低延时；3）高平安；4）凋谢。在这四个指标之上是围绕这个接入服务配套的运维体系，帮忙最终用户获得良好的端上体验的同时，帮忙开发者疾速构建本人的业务。  如上图所示，在整个接入服务上咱们划分为两层： 1）接入网关：负责连贯的放弃、音讯的解析、音讯的散发；2）利用网关：实现各种应用层协定：API、SYNC、RPC、PUSH等，在利用网关的背地是具体的业务零碎。同时咱们建设了一个对立调度服务，而不是采纳传统的DNS，调度服务是咱们的控制中心，通过它咱们能够强有力的指挥咱们的客户端，并且不会受到DNS净化的影响。 与服务端的分层架构对应的是客户端的SDK，最底层的对立网络库SDK集中了咱们对网络优化的策略，并向上为各个利用网关技术的SDK提供API。 基于下面的凋谢架构，业务方能够抉择间接凋谢具体的后端服务对接不同的利用网关，不须要理解网络背地的细节，并通过利用网关如API网关提供的开发工具疾速生成客户端代码。业务方也能够基于这个接入层设计本人的协定。 对立接入层集中管理了用户的设施、在线状态，并提供信息的双向传递能力。 如下图所示： 网关将致力于解决两头网络的通信，为下层的服务提供高质量的双向通信能力。 6、稳定性与容灾稳定性与容灾是服务端中间件永恒的主题，对立接入层这样一个汇聚网关收益和危险是并存的，一旦这个入口故障了，波及的用户范畴是不可设想的，如何做的更加稳固，是一个微小的挑战。 6.1 网关架构的优化对于一个对立网关来说，对接的业务网关的信息传递特点是不一样的，大部分的业务在全天都是比拟平缓的，然而个别营销类业务会在短时间内公布海量的信息，这样的信息发布会抢占网关的大量资源，对于用户的失常拜访会产生影响。 举个例子：push服务须要通过网关推送2亿条音讯，而这些音讯须要在短时间内全副推送完，而同时网关在为失常的用户的交互提供服务，海量信息的推送和失常的用户交互相互竞争资源，最终会造成失常用户的交互失败，对于业务来说，这是不可承受的。 基于下面的状况思考，整个网关在布署上分为两个集群： 1）一个集群解决常态的在线用户拜访；2）一个集群解决海量信息的推送。如下图所示，通过这样的形式，防止了业务状态不同，对对立网关的冲击，将不同的业务状态进行了隔离。 6.2 异地多活在异地多活的整体计划中，对立网关承当了疾速疏导流量的职责，也是这一计划顺利施行的一个重要环节。 异地多活是一个多机房的整体计划，在多个地区同时存在对等的多个机房，以用户维度划分，多机房独特承当全量用户的流量；在单个机房产生故障时，故障机房的流量能够疾速的被迁引到可用机房，缩小故障的复原工夫。 6.2.1）无线接入层单元化的协商机制： 先看一下web端在这异地多活中的实现形式： 从上图能够看到，浏览器的业务器求会发给CDN，由CDN上保留的散发规定，向后续的单元机房散发。 无线端也这样做吗？ 1）客户端领有弱小的能力，能够做的更灵便；2）CDN的散发节点带来更多的机器老本；3）对于须要双工通信能力的客户端，音讯投递更为简单。这些是咱们思考与WEB不同的中央，是不是能做些不一样的抉择？ 如上图所示, 咱们借助了客户端的弱小能力，利用协商的机制来实现用户的申请正确被调配到不同的单元。 含以下几点： 1）客户端的申请始终带上以后用户归属单元的信息；2）当申请达到服务端时，服务端判断用户归属单元是否正确，不正确将用户重定向到正确的单元 ；3）以后申请由网关在服务端上通过跨单元调用保障业务的正确性；4）当客户端归属单元更新后，后续的申请都会发到正确的单元机房。6.2.2）无线接入层单元化的旁路调度： 协商机制看起来很不错，这里一个重磅炸弹丢过去了，机房的入口网络断了！ 如上图，外网不可用，协商的机会都没有故障单元的用户无奈复原，这时旁路的调度服务出场了。 如上图，咱们设计的调度核心这时又承当了单元化的旁路调度职责，当app拜访的单元无法访问的时候，app会拜访不同单元的调度核心，询问用户的归属单元。通过这种形式获得可用的单元节点，将用户切到正确的单元。这个计划同样实用于单机房的接入层网关不可用的场景。 ...

摘要：在广告展现数肯定的条件下，点击率的高下就是决定一个广告是否被更多人看到的因素。本文次要针对“点击率”这一因素进行剖析，与大家分享。在广告展现数肯定的条件下，点击率的高下就是决定一个广告是否被更多人看到的因素。本文次要针对“点击率”这一因素进行剖析，与大家分享。 本文为Rambo同学以项目分析的架构，从多维度开展剖析。全文共4000+字，倡议珍藏。 P1 剖析背景及目标这是一份淘宝平台的广告展现/点击数据，本次剖析须要从这些数据中发现某些法则或者异样，进而给经营团队提出倡议。 评估一个广告成果的指标就是广告的点击人数，能够反映一个广告有多少人违心点击查看广告的内容，只有广告被点击，后续转化为购买行为才会产生。 把广告的点击人数指标拆分： 广告点击人数=广告展现数 x 点击率 而广告展现数又由广告商品的价格、类别影响；不同人群对不同类别商品有着不同的爱好，从而影响广告的点击率。 在广告展现数肯定的条件下，点击率的高下就是决定一个广告是否被更多人看到的因素。 因而本次剖析就针对【点击率】这一因素进行剖析 P2 剖析思路从“广告”和“用户”两个角度进行剖析： 1.广告角度剖析不同广告的商品价格对点击率的影响 剖析哪些类别的广告点击率更高，哪些类别的点击率低 2.用户角度剖析性别和广告点击率有什么关系 联合聚类分析与RFM模型剖析用户群体对广告点击率有什么关系 P3 剖析过程数据荡涤 1、数据概览原始的数据集中包含三类数据，具体数据对应属性如下： 为了不便剖析，抽取其中的局部字段作为剖析。 从raw_sample数据集中抽取：用户ID、广告ID、是否点击 从ad_feature数据集中抽取：广告ID、类目ID、广告商品价格 从user_profile数据集中抽取：用户ID、年龄层、性别、购物档次 2、数据组合将三张数据表，组合到一张表中 a=raw_sample.merge(right=ad_feature,on='ad_id',how='left') b=a.merge(right=user_profile,on='user_id',how='left') 失去一张记录了用户-广告信息表 3、缺失值解决3.1 源数据中还有许多的缺失值，将性别和年龄层字段中为空值的记录删去 3.2 异样值解决 查看广告商品价格字段的属性值范畴： 还是存在数据值过大的异样值，为了不便剖析对价格字段进行切分，选取更贴近日常生活的价格在1000元以内的广告记录进行剖析 切片之后仍保留了751570条记录 4、数据字段整合对于广告商品价格字段，每个广告的商品都有各自的价格，依据价格字段不便于进行统计。新增一个字段“price_class”代表价格的区间。 （0-价格在0-100元、1-100-200元、2-200-300元...） 联合图表剖析1、剖析不同广告商品价格对点击率的影响①将广告商品价格分类 将广告按价格分为100元以下、200元以下、300元以下等10类，并计算不同价格区间中广告的点击率状况。 从图中发现，所有价格区间商品的点击率都在5%左右，其中广告商品价格在100元以下的广告点击率最高，为5.92%； 看到价格较低的广告商品点击率更高，咱们个别认为是对价格敏感的浅层用户（收费用户）在这方面的点击率更高，而领有肯定消费行为和生产意识的中层、深层用户（付费用户）则更在意购物时的体验以及商品的品质。 为了验证以上说法，咱们先假如100元以内的广告商品次要的点击对象是浅层用户，再通过数据验证。 ② 剖析100元以内广告商品点击率的用户组成 查看点击了100元以内的广告商品的用户的用户组成 从用户散布能够看出，在点击了100元以内广告商品的用户中，深度用户的比例更高，占比81.6%，而浅层用户的占比则绝对少很多。这颠覆了咱们原来的假如。 小结：17年5月6日至17年5月12日这8天里的广告点击率现实，但因为不足去年同期、往年上月的数据，不足以判断5%左右的广告点击率是否是一个失常程度，有待更多数据验证。 高价广告商品点击率更高，且点击用户中绝大多数是深度用户。倡议：能够把这个数据反馈给广告投放部门，在这个区域优先投放广告，既能够对浅层用户进行流量变现又能让广告让更多具备生产志愿的中、深层用户看见。 2、剖析哪些类别的广告点击率更高，哪些类别的点击率低因为广告的类别数量泛滥，大部分类别的广告只有1-2次的展现，数据样本太小，因而选取展现数量最多的7个类别进行剖析。 ① 找出展现数、点击数、点击率最高的广告类别 能够看出类别6261广告的展现数、点击数、点击率均为最高，而类别4385广告的展现数尽管有10000+，然而点击数、点击率却是最低的。 ② 剖析类别4385广告成果最差的起因： a.先按【广告商品价格】来剖析计算没有被点击的类别4385广告的商品的平均价格 ...

导读：作者从 17 年双十一前开始接手天猫搜索前端，开发第一个需求—— H5 凑单页，到今天已经将近两年了。在这两年里，天猫搜索的前端体系发生了比较大的变化。今天分享一篇阶段性的总结文章，记录天猫搜索前端技术的过去、现在，以及自己作为业务目前的唯一前端对未来的思考。大体划分 首先基于前端技术的演进，大体上可以将天猫搜索前端的发展历程和未来趋势总结成几个时代： PC 时代H5 时代MV* 时代Weex 时代搭建时代深度搭建时代智能时代之所以这么划分，主要是基于天猫搜索的前端技术方向以及天猫乃至淘系前端技术体系发生的较大变化。而在这其中可以再提炼时代的关键词： 封闭：PC 时代、H5 时代、MV* 时代开放：Weex 时代、搭建时代、深度搭建时代智能：智能时代下面就来介绍各个时代天猫前端的技术状态和一些思考。 1、PC时代PC 时代可以说是天猫搜索前端的上古时代，那还是手机流量非常贵的 3g/2g 时代。因此大多还是简单的 WAP 页面，大多数人都还是习惯用 PC 进行购物。 ▐ 技术方案 模块化 PC 时代的前端技术方案采用的是 KISSY + MUI 3 ，MUI 3 就是那套 KISSY 的模块规范 KMD 。页面上还有一些非常老旧的 YUI 依赖。在那个 jQuery 王霸天下的时代，基本上天猫的 PC 页面都是采用集团内部根据 YUI 自研的大而全的 KISSY 框架。KISSY框架包含了前端所需要的几乎所有基础功能：模块加载器、 DOM 操作、事件处理、异步请求等等。 页面渲染 PC 天猫搜索采用了同步渲染的方式，页面的主要内容通过 VM 模板渲染输出到前端，因此前端需要维护大量的 Velocity 模板代码以保证 HTML 中的内容和自己 JS 代码能够配合得当。需求修改一旦涉及到 HTML ，就需要改造 Velocity 模板从而陷入 aone 发布的同步模板和部署炼狱之中。 ...

我叫切斯，是阿里巴巴的一名产品经理。今天和大家说说一个上线刚刚6天，已被500多万网友疯玩的AI——垃圾图像识别，可见垃圾分类苦天下网友久矣。 以下是一个产品经理的碎碎念~ 有人说它是“国内首款真正的垃圾图像识别产品”，对着物品拍照就可以知道这是哪一类垃圾。我不知道是不是真的首款，网友说是那就姑且是吧。 话说网上热议垃圾分类时，阿里的小二们也没闲着，内网里展开了热闹的讨论： “AR扫一扫”的解决方案被提了出来，但是质疑的声音也很大—— “到底能不能行”“用户真的需要这个吗”…… 真正让这个“孩子”获得准生证的理由，是因为公益与责任的力量。正如一位阿里合伙人所说，“AI的谐音是‘爱’，大家对‘AI’是有宽容度的；而且只有人人都能为这个‘AI’而努力，共同参与起来，才能让他更好”。“现在还是在上海这样的一线城市，用户对垃圾分类就已经如此困惑。未来这个意识扩展到中国的每一片土地时，人们一定会更加需要这样的帮助。阿里巴巴一定要为这个社会去承担责任”。 经过48小时的紧急开发，这个AI智能识别垃圾功能（测试版）在手机淘宝上线，功能通过阿里云搭建。 为了更准确实现AI识别，阿里的工程师志愿者们还与公益环保组织合作，紧急搭建了首个互联网垃圾分类数据库；天猫精灵团队甚至连夜支持了图像识别之外的文本识别的能力。 为了让它快速学习，程序员和设计师小哥让我把它扔到了阿里内网里接受测试和训练。 在这48个小时里，为了让孩子早点诞生，开发同学一下飞机就匆匆赶回公司；设计师小哥凌晨三点还在改视觉设计；程序员凌晨两点对我这个产品经理说：“你放心回去吧，今天不管多晚我一定把bug 改完发布上线……” 30多位志愿者分别来自社会公益、达摩院、天猫精灵、闲鱼、淘宝等团队。 “垃圾分类”的AI上线后，身边的每个人都拿着手机做测试，我的心情是既开心又紧张。兴奋的是越来越多的志愿者主动加入到了推广这个AI，“抚养”它“教育”它的行列，他们来自各行各业，有年过七旬的老人，也有在校的大学生……我知道这只是个开始，距离它真正长大还有很长很长的路要走。 在淘宝AI垃圾分类识别系统上线前后，支付宝、天猫精灵、盒马等APP也推出了不同的垃圾识别功能。就在刚刚，我们淘宝拍立淘还联动闲鱼对手淘AI识别功能进行了升级，闲鱼将免费上门回收网友识别出来的可回收垃圾。 改变世界的不是技术，而是技术背后的温度。改变世界的不是空想和讨论，而是从我做起、从此刻做起的决心与行动。希望未来的一天，每个人都会感谢自己给这个世界带来的那些微小而美好的变化。 每个人的一点点改变，终将汇聚成大大的能量，从今天开始就比明天开始早行动了24个小时。 垃圾分类，从我做起！爱护环境，人人有责！ 本文作者：会分类的橙阅读原文 本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

阿里妹导读：MNN（Mobile Neural Network）已于今年5月7日在 Github 上正式开源。淘宝无线开发专家——陈以鎏（离青）在 GMTC 全球大前端技术大会为大家分享了 MNN 开发、开源中的思考与总结，通过淘宝在移动 AI 上的实践经验，你将会了解移动 AI 的发展状况和应用场景，以及通过端侧推理引擎了解移动/ IoT 深度优化策略。开源与背景 人工智能从 2006 年开始，迎来了第三次浪潮。随着 AlphaGo 在 2016 年、 2017 年先后战胜李世石和柯洁，人工智能彻底进入了公众的视野。人工智能大热的背后，是大数据的积累，是深度学习的发展，也是设备算力的提升。与此同时，深度学习的框架也在不断演进 —— 从 Torch、Caffe 到 TensorFlow、PyTorch ，再到更面向移动端的 CoreML、NNAPI、NCNN、MACE 等。淘宝的深度学习推理引擎 MNN 也于 2019 年 5 月宣布开源。 MNN 是一个轻量级的深度学习端侧推理引擎，核心解决深度神经网络模型在端侧推理运行问题，涵盖深度神经网络模型的优化、转换和推理。目前，MNN已经在手淘、手猫、优酷、聚划算、UC、飞猪、千牛等 20 多个 App 中使用，覆盖直播、短视频、搜索推荐、商品图像搜索、互动营销、权益发放、安全风控等场景，每天稳定运行上亿次。此外，菜鸟自提柜等 IoT 设备中也有应用。在 2018 年双十一购物节中，MNN 在天猫晚会笑脸红包、扫一扫、明星猜拳大战等场景中使用。 开源地址：https://developer.aliyun.com/... MNN 项目从 2017 年开始启动，在经历一年多的开发迭代并通过了淘宝双十一的考验后，于 2018 年底启动开源计划，在历时小半年的开源改造后，今年 5 月份正式在 Github 开源。 开源首先还是因为经历过双十一之后，我们觉得自己做好了准备，开源有助于我们鞭策自己，把 MNN 做的更好；另一方面，业界的开源方案，不论是 TensorFlow Lite 、 NCNN 还是 Mace ，都给了我们很好的输入和借鉴，我们也希望借着开源，将我们的思考和创新回馈社区。 ...

为了让大家对敏捷有更多的了解，小编特意采访了阿里巴巴高级技术专家、敏捷教练张燎原。他是如何看待敏捷、如何帮助团队落地敏捷的，作为研发团队的一员，我们可以从哪些地方着手敏捷，以下是对他的采访。 嘉宾简介：张燎原，阿里巴巴高级技术专家，他是敏捷和精益方法的积极实践者和推动者，具有十多年软件研发一线实践经验，经历过消费电子、通信及互联网多个行业，长期从事研发管理、研发教练及组织转型工作，曾负责Nokia全球大规模敏捷导入实施和转型辅导，成功帮助淘宝、闲鱼、阿里云等事业部引入精益产品交付和创新方法，帮助实现DevOps转型。译有《程序员度量》、《软件驱魔》等。同时，他热衷编写代码和开源，涉及软件设计、测试驱动开发、代码重构、遗留代码的维护和持续集成及交付。工作之余，他还擅长画画和摄影，被同事戏称“最会画画的敏捷教练”。 1、燎原你好，我知道你是敏捷和精益方法的积极推动者，在阿里也辅导过淘宝、闲鱼等多个团队。从事敏捷这么多年，特别好奇，你是如何看待敏捷和精益的呢？ 张燎原：以前，敏捷作为一个很时髦的概念，大家总是反复在提，就像现在的DevOps一样。在我看来，不论是敏捷、精益还是DevOps，能不能解决问题， 这个才是最重要的，一切不以解决实际问题的概念炒作都是耍流氓。去年我和何勉老师（阿里巴巴敏捷教练团队负责人）在一起讨论， 我们是在做敏捷、精益的转型还是其他的什么，后来我们决定提升研发效能。作为一个研发团队，能够持续快速高质量地交付有用的价值，才是我们觉得作为一个研发团队要追求的。 提升研发效能，主要分两点来看，第一个是回答如何持续快速高质量的交付的问题。在交付团队里，大家协作特别好，写的代码要没有太大的问题——高质量，发布特别快。所以，我们知道的比如看板、Scrum是解决我们协作的问题；测试自动化、CI/CD以及DevOps是为了帮助高质量的发布；我们提倡的DDD、Clean Code，是为了让我们的代码能够更健壮、质量更好、更Clean，大家在协作的时候，能够通过代码来交流，这些都是提升交付能力的手段和实践。 另外一点是，就要回答什么是有用的价值这个问题。对很多工程师来说，大家可能更关心代码写的好不好，从产品那拿到的需求，大家基本都认为是对的。很多时候产品提了一个需求，一个工程师可能要做一天甚至是一个礼拜才能完成这个需求。但是，如果这个需求没有价值，那就相当于白干了。所以这个时候，我们要走到源头去看一看，这个需求是否是有用的，对我们的业务有没有帮助，是否值得我们投入。 所以你问我如何看待敏捷，我不会说是要快速响应变化，因为我觉得这样还是有点抽象。回到研发的本质，我们是要持续快速高质量地交付有用价值，从解决阻碍我们达成这一目标的问题出发，选择相应的方法和实践，最终解决掉这些问题，这才是实实在在、对我们有帮助的。 2、你是如何帮助团队落地敏捷的，这中间有没有遇到一些困难？ 张燎原： 我觉得首先是让大家看得见，对问题形成一致的理解。当我们开始在团队落敏捷时，大家会说我没有问题，所以首先我们要让大家看得见问题，在问题上达成共识。这样，目标才会一致，做事才能齐心。 其次，大家在解决方案上要达成共识。有的时候，针对一个问题，可能有A解法，也可能有B解法，但我们要一起探讨是用A还是用B。例如，B可能见效快，但不持久；A见效慢，但是持久。这个时候，我们得去找一个折中的解决方案。 再次，要有一条明确清晰的改进路径。解决方案要能解决问题，但同时也要给大家改进的信心。每个阶段都能解决一些问题，通过持续地发现和改进问题牵引着大家往前走。这种改进不应该都是烟斗式的，即开始会导致效率先降下来，然后才会慢慢持续往上爬。 最后，有节奏地给出有效反馈。通过在合作过程中，通过数据也好，或者观察到的问题也好，持续地给团队反馈，让大家明白自己是在正确的路上行走的。 这几点对我们来说都是比较大的挑战，但比较好的是，我们现在能驾轻就熟来应对。还有一点，大部分时间，我们是站在全局的视角来看问题，这和具体的职能团队是有差别的，他们更多是站在自己的职能的角度。大家看问题的视角不一样，在沟通的时候，也就需要更有同理心。 3、在敏捷实施过程中，给团队建立信心真的很重要，能具体说说你是如何在短时间内给团队建立信心的吗？ 张燎原：在实施转型或提效的时候，需要持续地给大家信心。我们不太建议一股脑地给一个完整的解决方案，把之前的全部推翻掉，就按照新的来。因为我们接触的团队，基本上都是工作在现有的业务上的，哪怕是创新型的一些团队，大家之前也一起磨合了很长的时间，大家都有自己熟悉的工作方式和习惯。 我们团队之前有一个案例：《4个迭代，从批量交付到持续交付转型》，就非常典型，每做一个迭代都是让大家看到收益，然后才有信心做第二个迭代。例如，当时的第一个迭代是把所有的职能端到端的拉齐，让大家看到整体。这个时候就减少了各个职能之间的交流误会，整个沟通就顺畅了。然后在整个可视化的协作流程中，大家就会发现：喔，原来需求有这么多反复、原来需求太大了，甚至需求都没搞清楚就开始了。其实很多时候，这些都是大家自己发现的。当解决了协作的问题，大家有了信心，就开始着手解决需求的问题。当需求澄清的问题解决后，又会发现发布速度是不是可以更快一点，原来一个月发一次，现在是不是可以每个礼拜都能发。这样每一个迭代都会有一些点得到了改进，并且也能够持续暴露其他的一些问题，能够让大家朝比较理想的状态前进。 如果你告诉大家落一个解决方案需要半年的时间说半年之后才能看到结果，你做了一个月没结果，大家能接受，第二个月没结果，大家可以坚持，如果第三个月还是如此，可能就没有然后了......这是我们在制定解决方案的时候需要特别考虑的。 4、你们的敏捷实施或提效一般多久能见到效果？ 张燎原：从目前在阿里接触的一些团队来说，一个月内，基本上就能够看到一些明显的效果了。当然这跟我们合作的团队也有很大的关系，大家彼此都挺配合的，甚至有的时候他们比我们还专业，他们会说，燎原老师，你看这种方式是不是会更好。然后我发现他给出来的点可能是我都没想到的，所以在这个过程中，我们也是在相互学习。 当然，改进是一个持续的过程，目标越大，要投入的时间可能就会越长。 5、一般什么时候可以判断说这个团队辅导OK了？ 张燎原：一般情况下，在辅导开始的时候，我们都会有特别明确的目标，我们会清晰地把需要改进的问题定义出来，让大家看得见，找出根因，而不仅仅是现象。随着问题逐渐被解决，后面我们会有意识的慢慢抽身出来，看没有我们的时候，是不是也能够work起来，如果我们发现没有我们也行，这个时间也就到了。 在这个过程中，很重要一点，我们要善于发现和培养有潜力的同学，在被辅导团队留下种子，这些同学会是团队持续改进的生力军。 6、有什么方法可以帮助一些团队发现自己的问题？ 张燎原：我觉得能做IT的人都是聪明人，如果他没有发现这个问题，更多的是因为他没有这个意识，没有意识到自己要去看有没有问题。所以我们会通过其他的一些渠道，让大家去意识到这件事。老实说，大家不缺方法，缺的是意识，我们希望能够让大家意识到这件事情的重要性，如果我们没有一个很好的研发能力去支撑业务效能的话，我们也很难把业务效能做好。虽然很多时候我们只觉得业务效能很好很重要，我承认确实很重要，但研发效能是基础。如果你有一个很好的点子，但是没有很好的这种研发团队，没有研发方式来支撑。你的点子，也实现不了。 7、如何让更多的有需求的团队也能得到你们的支持？ 燎原：确实，让我们去辅导一个团队，肯定没有问题，但是如果让我们同时去辅导很多的团队，精力肯定就忙不过来，一个人一天就24个小时。这个时候我们会有一些策略，例如，就像前面所述，我们会培养业务团队的一些同事，让他们成为这方面的专家，就像一颗种子，他也会发展壮大，然后他自己做的一些事情，对他所在组织都会有很大的帮助，这是一种杠杆撬动的力量。另外，我们还会通过其他的一些手段，例如线上、线下的培训课程、最佳实践文章、案例分享，以及鼓励更多同事把他们一些好的点子share出来。我相信这样一个一个的点，都能够帮助规模化。 还有另外一个很重要一点，我们所在的研发效能团队，通过各个业务部门的实践，对实践方法及不同场景的总结沉淀，会形成一些体系化的东西，然后与工具做更多的结合，让大家通过工具就可以轻松上手，把好的实践最大化。例如，现在Aone的看板，看板上为什么分那些阶段、为什么有那样的一条条泳道、需求是怎样移动的，最早我们是用物理看板，但是现在我们把它都融入到产品里，团队建好自己的项目空间，就自动会有一块项目看板，从而让好的实践在更多的团队得到使用。 8、作为研发团队的一员，我们每个人可以如何着手去实施敏捷？ 我觉得单独从了解方法或知识的角度来说，看完了一本书或者一篇博客，10天半个月可能也就忘了。但是我们可以从自己现实当中的问题出发，比如做为程序员可以去思考，如何能够让代码变更高效地发布。例如你可以搭一个持续集成的流水线，让大家的代码一提交就触发自动化的检查、自动化的测试和部署，把这个做好就是往敏捷，往研发效能的提升上就走了一大步。 对产品经理来说，需求应该如何组织，是否都有对应的目标，任务朝需求对齐，需求朝目标对齐。对于一线管理同学，可以思考整个团队的能力模型，团队的协作当中有哪些问题，比如测试和开发同事、前端和服务端之间的协作有没有更好手段，让大家的协作更高效。这样每个人都站在自己的角度上，改进一点点的话，形成合力。大家再在站在系统的角度，串起来一起看，就会改进很多。 即使是一个刚入职场开发同学，也可以思考代码能不能写的更clean，减少code smell，把这代码写的别人一看就懂，每一段代码都能有很好的单元测试，减少维护成本。这些都是在提升研发效能，在实践敏捷。敏捷不是挂在嘴上，而是落在每天的工作里。 9、最后，本周六你的分享《从持续交付到业务创新》，希望能给大家带来哪些收获？ 张燎原：很多时候我们做工程师，都是站在自己的位置去看待问题，很少有机会能够站在全局，端到端的角度去看待问题。这次分享我希望能够带着大家一起，从研发的端到端、从需求到交付，去了解我们可以通过哪些手段去提升研发效能，以支持我们提升业务效能。 对于每一个不同的角色，能够富有同理心地去看待软件研发过程中的其他职能的工作，真正做到“眼高手低”：即看到整体，落到实处，整体形成合力，往组织效能最大化的方向去努力。 阿里有一句话叫做：一张图、一场仗，一颗心，首先画好一张整体的图，把团队之间协作的图画好，我们才能得对齐，上下同心，然后把这场仗打好。期待与大家的交流。 本文作者：云效鼓励师阅读原文 本文为云栖社区原创内容，未经允许不得转载。

国内的前端行业，是一个群星璀璨，同时又有些纷纷扰扰的圈子。很多初出茅庐的年轻人怀着改变世界的梦想，谁也不服谁。不过，有一些为前端领域做出贡献的拓荒者几乎受到所有人的尊敬，玉伯就是这些拓荒者中的一员。 如今，他已经是蚂蚁金服研究员，带领着体验技术部，打造出 Ant Design、AntV、Eggjs 等广受欢迎的开源项目，他所在的团队也成为国内前端开发者向往的地方。 在同事眼中，玉伯是一个严谨的人，同时保持着对生活的热爱，他曾以 lifesinger 为笔名写名为“岁月如歌”的博客、参与 GitHub 上的开源社区，到现在也经常在知乎上分享自己的知识和见解。 从中科院到支付宝时间转回到 2006 年，当时在中科院物理所进行硕博连读的玉伯对前途产生了迷茫，是就这样继续深造，将来投身学术界，还是出来干一番事业？ 当时，腾讯的 QQ 已经开始有所起色，在年轻人之间开始风靡，淘宝网已经成为中国最受欢迎的线上购物网站，互联网正风起云涌。这时，玉伯得知中科院软件所正在找人，一番思考之后，玉伯毅然放弃学业投身到软件行业。由于他当时年龄小，在软件所工作期间，经常闹出被误认为是学生的笑话。 中科院的生活单纯但缺乏激情，2008 年，玉伯终于离开了象牙塔，南下杭州，加入了当时正在招兵买马的淘宝 UED。虽然并非科班出身，但玉伯从 2002 年起就已经开始接触前端开发，从此与前端结下了不解之缘。 加入淘宝 UED 后，他与承玉等人一起研发了 Kissy，当时淘宝前台业务的标准前端技术栈，并将之开源，在 GitHub 上，Kissy 一度是阿里系开源项目 Star 数最多的项目。 在淘宝期间，玉伯还发起了 Sea.js，一个开源的 JavaScript 模块加载框架，它契合了前端工程化的演进趋势，也是现代大中型前端项目的基础。 2012 年，玉伯加入支付宝前端开发部，负责基础技术组。第二年，他遇到了职业生涯的另一个重大选择：阿里宣布“ALL IN 无线”，支付宝前端解体，所有人都面临选择，要么转岗去做移动端开发，要么留下来做中后台的前端开发。玉伯选择留了下来。 虽然从事后来看，无论是走的还是留的，结果都挺好的，但当时对于玉伯是一个痛苦的时刻，甚至对前端的价值产生了怀疑，他在《阿里前端的困局与突围》中写道： 一个事实：把国内大部分公司的 UX 部门解散掉，也不会太影响产品的体验。在国内，UX 主要还是起到美工的作用，虽然我不想承认。前端依旧是美工，而且仅仅是实现工。 在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。不过好在，他很快振作起来，从中后台业务中找到了前端的价值。 “后来我们发现中后台业务也是有很多事情可以去做的，无论是业务还是技术都值得深挖，只是以前前端只关注 C 端业务，但其实 To B 的业务对前端来说是一片蓝海。”玉伯说。 玉伯发现中后台的业务量其实非常大，如果没有一套系统的规范来应对，研发效率和产品体验都将面临挑战。 在这样的背景下，前端技术部改名为体验技术部，玉伯和他的小伙伴们踏上了新的征程。 冰山之下的体验意识到中后台方面前端体验的缺失，玉伯开始带领团队做这方面的工作，他还专门招募了设计师团队，和前端工程师一起工作，开始在体验方面深挖。 设计师的加入让前端团队发生了巨大变化，也让玉伯开始思考体验的更深层含义，他在《我们是如何从前端技术进化到体验科技的》一文中表示： 前端技术再牛，都很难直接解决产品层的用户体验。对中后台产品来说，设计的价值也远远不止于让产品的颜值提升，设计的更多价值，在于深入到产品的业务逻辑里去，去帮助业务梳理产品信息架构与任务流程。用户体验是一个非常综合的事，需要各种专业人士在同一个产品上聚焦发力，一起共同努力才能真正提升产品体验。他还引用乔布斯的话说：设计不止于好看，更关乎好用。 为了让前端工程师和设计师更好的协作，玉伯说，团队曾经开展过一个活动：任何设计师的要求都是合理的，只要设计师提出的要求都尽可能的去实现，除非技术上的确实现不了。这个活动让设计师感觉到前端工程师的尊重，增进了双方的互相了解。而且前端工程师和设计师都是视觉型动物，都关注人机交互的细节，所以相处下来很融洽。 2015 年，体验技术部推出了 Ant Design，它有别于 UI 组件库，是一种全新的设计系统，随着 Ant Design 不断的证明自己，它受到了阿里内外的广泛赞誉，也在一定程度上引领了国内业界关注中后台体验的风潮。 ...

背景介绍阿里很少提敏捷转型或DevOps，阿里是强业务驱动的，不管用什么办法，一定要达到业务目标。 我来自敏捷教练团队，我们的职责是帮助团队拿结果。这里的团队不限于研发团队，我现在支持的团队包括销售团队和产品运营团队。我们要帮助整个业务链上所有职能角色协作起来达成业务目标。 阿里同学对敏捷的态度非常有意思。大家有问题才找我，同时会提醒我一句话，“我们不在乎敏捷，只要解决痛点和问题就行”。所以阿里的同学非常实在，就是要见效，只要他感觉到有效果，原来痛的地方不痛了，原来不通畅的地方顺畅了，他就觉得敏捷转型的努力是值得的。 面临的问题我们更像一个内部顾问，团队带着痛点和问题来找敏捷教练，我们要贴着他的问题想办法，一起做实践的落地，一起评估效果。 迭代过了一半，需求还没定2016年5月底，我进淘宝直播团队的时候，主要的痛点是“需求定不下来”。当时直播跟电商结合还是新业务，没有人知道应该做成什么样。运营和产品一直在摸索。摸索的过程中有很多犹豫，这样需求出来的比较晚。手机淘宝一个月发一个大版本，可能离封版只有两周，这一版到底做什么还没想明白，开发和测试非常着急。 开发时间紧，加班赶工需求出来后，开发非常赶，基本在5-8个工作日把1个月的版本需求都开发完。一个大版本总要有些亮点，不能只做一些小改进。所以开发工作量很集中，这个时候开发都在玩命加班赶工。 质量不达标，版本发不出赶工是有代价的，赶出来的东西可能表面上看是OK了，但是内在欠的技术债比较多，质量容易出问题。手机淘宝用户量非常大，质量卡点非常严，有严重缺陷没修好绝对不允许上线。淘宝直播2016年3月底发布第一个公众版本（淘宝的用户都可以用），3月、4月、5月连续三个版本，每一个版本都没有赶上正常的发版节奏。要申请紧急发版，提申请的人超级尴尬觉得很没面子。 线上问题多，运营变客服版本发出去了，可是质量太差了，主播天天在说直播间怎么黑屏了，怎么闪退了。运营同学本来应该做一些拉新、留存，想一些玩法，结果很苦的在主播群里做客服，运营同学一片抱怨。 着手解决问题数据度量 我需要一个仪表盘快速了解团队。我们经常讲到底怎么去衡量一个团队是不是敏捷？或者现在有没有比过去更敏捷？有几个维度还是值得大家去看的。 速率怎么样?一个月能不能交付更多功能，或者交付功能的价值有没有提高。 周期时长有多长？从打算做一个功能到用户可以用上这个功能，享受到它的价值要多久。这个时长越短，团队的适应性越好，在短时间内能响应一个新需求并把它交付。 质量怎么样？很多团队敏捷转型的时候，一上来就追求快。短时间内是快了，却欠了很多技术债。过一段时间速率会下来，最后既没有快也没有好。我的思路是先保证交付的东西质量都特别好，一次把有价值的事情做对，去掉中间的返工、浪费。如果有很好的质量，架构演进会更容易，开发新功能会更快。从质量出发先好再快，长期来讲能够拿到又快又好的效果。 最后准时性很重要。在阿里尤其电商系，可能90%以上需求是倒排的。需求提出来老板不会让团队评估多久可以做出来，老板通常说这个东西很重要，什么时间之前一定要，而且不是光要功能，还要业务结果。阿里不看苦劳看功劳，我们直接拉业务指标看。 还有一个最重要的维度是业务目标。敏捷也好、DevOps也好，最重要的还是业务，如果业务没做好其他都是零。即便做了一百个功能，如果业务指标没上来也是白搭。对于团队来讲，老板跟你说10月底要达到什么样的业务目标，即便没有100%把握做到，也要找到一条可行的路，10月底前把这件事搞定，在阿里这样才是靠谱的。 接下来会讲我们怎么始终扣紧业务目标，做的每一件事情都可以帮助我们拿到业务目标。这点在阿里特别重要。我们会找一些具体的指标来度量这几个维度。 速率度量 完成需求数是一个简单的度量，说它简单是因为我们只度量了单位时间内完成需求的个数，我们没有算故事点数，也没有考虑功能大小。 如果需求非常大，意味着它的开发测试时间都会变长，第一次得到反馈的时间也会很晚。一个大需求如果拆成两个小需求，并且每个需求都可以独立发布，先上一个再上一个，其实是比完成一个大需求再发布更好。这个指标有一个积极的副作用是鼓励团队把需求拆小一点，逐步的迭代和优化。我会跟产品经理商量，有没有办法把需求拆到研发团队在5个工作日内可以提测这样的粒度。如果一个团队有四五个开发，一周之内搞不定一个需求，意味着这个东西本身很大或者很复杂。 这个度量指标提出来后有人问我，需求大小不均，为什么只算个数。我说是为了鼓励大家拆需求。他说为什么要拆需求，我说不要憋大招小步快跑。这样他自己会把逻辑理顺。 质量度量 看质量更多是看过程的质量，在提测以后发现缺陷的数量，还有严重缺陷和低级缺陷占比。如果同一批人，同样的周期，缺陷数量突增，就有点不靠谱了。从5月到8月缺陷数量有明显的下降。 严重缺陷很好理解，我们来看看低级缺陷。低级缺陷是傻子都能发现的缺陷。这个指标衡量的是提测质量。如果开发比较上心，对自己交付的东西有责任心，通常不会有很多低级缺陷。回顾会上我会问低级缺陷数量我们有没有办法降下去？团队商量后觉得一个月不应该超过十个，就变成一个目标了，团队会朝着这个方向努力。 周期时长度量 周期时长我们拆了三段：分析时长、开发时长和测试时长，合起来是总的周期时长。 6月的周期时长大概是30天，分析时长大约占了一半。需求准备的时间特别长，大家觉得应该花更多时间分析需求，以免没想明白。实际上我们会发现即便多一倍时间分析需求，也未必能把所有问题都想明白。我们做的是创新的事情，这里有非常多的未知，想在一开始就把所有坑找出来不现实。我们要在研发过程中去探索，而不是在前面增加复杂的流程和评审。 大家会发现从6月到8月分析时长缩短了，开发时长和测试时长增加了。尤其是测试时长从3天增加到了7天。以前我们是小瀑布模式：一个月的功能最后三天一起提测，测试同学加班到凌晨。后来我们改进为小批次逐步提测，迭代的早期开始就不断有需求提测，测试压力分布在整个迭代周期。 还有一点大家可能很困惑，为什么7月的时长这么可怕，如果翻到前面会发现7月份交付需求数量也变少了，这里面有一个很有意思的故事。7月有两个很大的需求插队进来，团队的并发增加了。那个时候看板上有些卡片好几天拖不动，因为开工了太多需求，研发同学根本顾不过来。7月是一个比较失败的版本，我把7月的度量数据拿给开发负责人，我问改进了一个多月，为什么周期时长反而变长了，完成的需求反而变少了。开发负责人非常聪明，说我们并发太高了，这时候我觉得不需要再多说了。其实数据的力量很强大，大家知道高并发的伤害，但是伤害多严重不清晰。数据显示出来，因为并发提高，增加了那么多等待，大家觉得这件事代价太大了划不来。 8月淘宝直播火了，不断有合作方找我们想要加塞需求。经历了7月版本，团队通过反思学会说不。到了8月，我们比较能控制自己的节奏了。 准时性度量 准时性我们看计划交付的功能有多少按时交付了。7月并发度提高了，速率并没有提高，准时交付率也下降了。我们6月和8月是100%准时交付 ， 7月没做到。没关系，只要找到原因，吃一堑长一智就可以了。 变化的背后聚焦业务目标 阿里是强业务驱动的公司，做任何事情在一个季度或半年，业务效果一定要被验证。淘宝直播是一个新业务，大家不知道往哪里去，这时候特别需要快速试错和验证。 我到手淘我也不了解他们的业务，就做了一个业务指标板，列出9月底要达到的目标，每个月发版后更新数据。 这些数据在BI系统里可以看到，为什么还要费力做个物理板呢？我观察虽然在BI系统里随时可以看到，并且大家都有权限，但是真正去看的就那么几个人，主要是运营和产品同学。研发 TL会看，一线同学一般不会看。大家也不太清楚正在做的功能对提升业务指标有什么帮助。 可视化以后，大家经常路过这个板，有时候就会聊两句，7月底了某某指标还没到一半怎么办，还有同学自告奋勇跟运营说有好点子，要知道以前都是运营说服产品和开发同学赶紧做。 业务主线 业务目标只是一个方向或者要去的地方，怎么到那里要有一个路线图，要有一个规划，这个规划是按季度做。产品、研发和业务三方负责人清楚季度规划，一线同学不清楚。后来我们决定季度规划定下来以后要分享给全员，所有人都要知道接下来三个月要去哪里，要攻什么目标，打法和策略怎样，分解到每个月要交付什么核心功能。这个规划就是我们的业务主线。 迭代目标 业务主线不落地也是空的，接下来迭代里的核心功能要扣住季度规划的业务目标和业务打法。我们做了比较狠的事情，产品经理不只要讲做什么功能，还要说明白做这个功能的业务价值在哪里，这个价值还要可度量。发布了这个功能以后看数据，比如直播间的观众有不同来源，有人从直播列表进来，有人从微博过来，有人是关注了主播从主播的直播预告列表进来，通过埋点可以知道每个来源对直播间UV的贡献。直播间UV这个月相比上个月有提升，到底哪个来源贡献比较大，上了哪个功能带来了这样的变化。有个新入职的产品经理以前做游戏直播也没有电商经验，但是她提的需求经过数据验证确实非常有效，大家非常信任她。反过来讲如果一个产品经理一次没命中，我们会觉得他运气不好，如果总是摸不中，再提需求可能大家要打一个问号。 迭代计划 我们的迭代计划可以一层层展开，从业务主线链接到核心需求。我刚去的时候他们刚好要发版，我问这个版本三个最重要的需求是什么。我分别问了三个开发同学，他们的回答不一样，有个开发同学直接跟我说做了很多，但是零零碎碎都想不起。6月、7月、8月我们主线很清晰。 迭代过程 迭代过程我们有物理看板，这是一个完整的端到端的板，这里只显示了一段。白色的是需求卡片，黄色的是任务卡片，红色的是风险、问题或缺陷，绿色的是谁做这个需求。我跟开发同学讲，每个人只有两张绿纸条，每个同学同一个时刻最多领两个任务，先领高优先级需求的任务，完成一个任务再领新任务。6月份开始用看板，集成封板前一天，我在钉钉上收到电子照片，所有需求在待集成那一列，然后开发TL跟我说感谢。之前连续三个版本都没赶上节奏，这次顺利集成了，大家都很开心。6月我们没有做更多的改进，只是把研发过程可视化出来，每天按照优先级的顺序更新今天进展如何，明天计划到哪里，有没有问题和风险。大家会有一种强烈的动力想把卡片拖到终点。 我刚进团队的时候大家觉得敏捷教练不干活，就是做了几个板弄了点数据，到底有什么用。大家也不太认敏捷这一套，比如开回顾会，我跟开发TL说开个回顾会吧，开发TL说代码写不过来没空开，我就说我很会控场，保证一小时之内开完。他有点活动心思，就开一个小时。回顾会开了以后，他觉得说的问题都在点儿上，改进行动也靠谱，就比较认同了。 去年双十一之后我离开淘宝直播去支持别的团队，今年1月底我去回访，发现他们的敏捷实践坚持得非常好，那个板比原来的更漂亮。阿里的同学都是价值驱动的，他觉得这个东西有用，才会坚持做下去。 快速验证假设 快速验证假设的工具在很多公司都有，就是A/B Test。在手淘A/B Test有非常好的技术支持，在APP里面集成SDK，服务端是现成的，很快可以接入。怎么样把工具用好是另外一个挑战了。 首页改版 当时想尝试在直播列表里透出直播信息，最容易想到把评论信息透出来，这样气氛能够感染到用户，吸引用户进来看直播。开发同学尝试了一个礼拜很苦恼地找我说，把评论透出来很麻烦，消息系统我们用了别人的，这个功能他们没有，要现开发一个。他们有一时排不上，就想看代码自己改，结果花了一个礼拜才调通接口，有没有办法可以快一点？我说最核心验证点在哪里，是不是透出来评论吸引用户进直播间？如果透出来的评论信息不是从消息流里自动获取的，而是在某几个直播间手动抓一些评论透出来，多久能实现？他说快的话今晚就可以搞定。先弄清楚验证的核心点是什么，再去看验证这个核心点最快最轻成本最低的方法是什么。 直播首页改版是很大的需求，我们不会所有东西一块做，而是拆成小点。每个点可以独立验证，而且非常轻，用户几乎感觉不到变化。这个例子里有两个点，一是底下赞的地方从静态变成动态，还有一个是从主播的静态图片改成直播间当前的十秒视频回放。这样可能气氛好一点，会吸引更多用户看直播。不需要PRD和交互视觉设计，运营直接和开发同学聊一下，大概知道要验证什么做成什么样，开发实现核心功能，推1%的用户做一个A/B TEST。数据如果有明显统计意义上的区别，可能摸对了，再按照做产品的方式精细地做出来。没摸对，成本肯定不会超过一个礼拜，这个事情不用再投入了。 一起打磨需求 需求为什么定不下来？ ...

导读：提到阿里云CDN，不得不提技术掌舵人姚伟斌（文景），虽然他不是团队中最“老”的同学，但他却历经了淘宝业务发展最为飞速的几年，见证了从最初服务淘宝和集团内部的CDN，到如今国内服务客户最多的云CDN的每一步技术蜕变。在他看来是业务在推动着技术的发展，技术带动了人的成长，过程中不乏迷茫和低谷，但最终确实是一次次的业务洪峰把CDN技术推向了顶端。 缘起开源 怀着赤子之心加入阿里读书时期的文景是个非常“爱折腾“的学生，经常去女生宿舍帮忙调通网络，也接了很多系统开发的私活项目。在研究生阶段接触到了嵌入式开发、无线传感网络、Linux，底层网络，向服务端开发转型。 当时比较火的是金融和通信专业，但是文景对开发就是如痴如醉的喜爱，虽然他的学习成绩不算拔尖，但是因为项目的实操历练经验丰富，他在毕业时候顺利的进入了一家互联网大厂。也就是在这份工作中，他接触到了很多服务端开源软件，如Nginx、Squid、Varnish、Lighthttpd等，也为后续进入阿里奠定了基础。始终认为开源对拓宽程序员的视野和提升代码水平非常重要，所以他开发了很多Nginx开源模块，因为不断的打磨，有一些项目在Github上有上千的星了。回忆当初，技术人员需要一定的价值认同，要么在业务上厉害，有上千万的用户，要么就是技术价值的认可，你做的东西不仅自己在用，成千上万的开发者也在用，甚至有国外的开发者会给你写感谢信，这是非常好的技术认可。 “后来当时的公司业务发展比较慢，遇到了发展瓶颈，而因为自己在开源领域的一些成就，被阿里看中。当时阿里属于业务早期，我心里怀疑这公司到底行不行，没想到面试官竟然是开源领域非常有号召力的“大神”，我当时立刻就决定加入阿里了。有时候程序员选择一份工作不是看业务多强大，而是身为程序员的梦想使然。“文景说。 来到阿里后，文景负责Tengine的研发，从一个人单干，逐渐发展到小团队，Tengine也成为集团95%以上业务的入口。在阿里节奏很快，业务每年的增长几倍甚至几十倍，这十年来有三千倍的增长，这过程中也深刻体会到人和公司的成长是同步的。Tengine业务复杂度非常高，支持整个阿里集团的业务。作为一个支撑性的部门，更需要自驱力，主动做好，主动邀请别人来使用，并且在期间主动解决问题让业务变得更好。 在阿里这么快节奏的工作环境之下，文景还坚持付出额外的时间来做开源，有一段时间Tengine曾跻身全球前十的WebServer，这也是团队成员至今都非常自豪的事情。 这十年，双11和这些程序员“相爱相杀”文景很幸运，加入阿里的第一年他就赶上了双11。对于当时的淘宝技术人来说，双11是每年最最重要的事情。“对我们来说，最关键的就是在零点那一刻，系统要扛住，降级的措施越少越好“。文景回忆到，当时的技术原则：第一是要对业务有预估，几千万人同时并发的QPS是多少，系统能不能支持；第二，要做技术预案，所有依赖系统的容量是多少，一旦出了问题后的应对方案。”经过头几年双11考验后，系统逐渐具备了在极限的情况下也能正常运行的能力，在高性能、稳定方面有很大提升。到后来，我们技术能力和资源储备，已经远超当年秒杀的规模，当前的技术架构已经足以支撑，所有的技术人这才安心了。“ 当然，技术的积淀并不是一蹴而就。在这种高强度的业务压力下，基本上所有的瓶颈都会被文景团队遇到，内存、CPU、IO、网络，来来回回做了很多轮软件优化和节点架构升级。为了应对峰值压力，团队也提前准备业务锁量、节点压测、降级预案、采购临时带宽等多种措施。在我们的监控和数据还不完善的那个年代，双11就靠每个人打开多个终端，盯着一批节点，一旦发现机器负载过高，立马进行人工干预。 转眼来到了2012年，文景认为这一年对CDN非常关键：“第一，我们决定不再采用外部的商用CDN，因为我们发现淘宝的流量，商用CDN是不足以支撑的。原因是淘宝是中国第一个图片这么多的网站，当时的SSD机器还没有这么流行，大部分的CDN厂商还在用SATA的机器，遇到数据量激增的时候，它的IOPS跑不起来，节点立刻会挂掉。第二，当大部分CDN厂商都在用千兆机器，淘宝CDN已经在用万兆机器，我们是中国第一个使用全SSD机器的厂商，并且完成了40G能力的节点上线。当时的技术架构是非常领先的。” 随后的几年，随着CDN能力的增强，双11扛住了数十倍的业务峰值流量，而且很多业务已经开始使用CDN，比如秒杀、红包、详情页等。后来CDN不仅支持集团内部双11，也开始服务外部客户。那几年的发展可以用一路狂奔来形容，每年都有新的业务产生，比如HTTPS、直播、短视频等，文景带领着团队不仅要做产品商业化、要贴身服务客户，还要去快速适应并调整面向新业务的技术方案、优化用户体验、技术攻坚、节点建设，同时也要对集团和客户的双11做全链路的保障方案，双11每年带宽增速在50%-100%，文景的脚步从未停歇。 跌倒了，爬起来继续上路狂奔这一路，文景经历过高峰，当然也有跌落低谷，他认为2015年对团队来说意义非凡，因为那一年他们险些背了3.25。当时淘宝上了全站HTTPS，而由于前期压测、对新业务的评估没有做到位，全站HTTPS带来的计算开销导致CPU、内存都开始成为瓶颈。“当双11开始后，别人都在为数据再创新高而欢呼，我们团队的工程师却眼睁睁的看着线上一些节点内存被打爆，不停重启，当时我在客户现场驻场，真的连死的心都有了。”文景回忆到。 当时的CDN团队已经到了阿里云，经常全中国到处跑，深入客户现场，贴身服务，整个团队的工作重心不再仅仅是为双11做方案和保障。“我们从纯碎的技术人，变成了需要有商业思维的架构师，用CDN这个产品帮助客户去解决问题。也正是因为如此，这次的经历给我们敲响了警钟，后面每当新业务诞生的时候，我们都做足了充分的预案，坚决避免再次重现，更绝不容许这种情况出现在客户身上。” 在此之前，文景带领的CDN团队已经进入阿里云，完成了从“甲方”到“乙方”的转型。“我们还是很偏技术思维的，我们认为只要把自己这块的技术做好做透，一切就顺理成章了。最开始我们在Tengine团队才不到10个人，是纯技术团队，负责软件开发。在转做CDN后，我们要去owner整个系统，考虑的东西更多，系统稳定性是第一优先级。如今，到了阿里云，我们需要吃透业务，所有技术人员都要去跑客户，去了解客户的需求，研究如何更好的服务他。这对我们来说其实是一个角色的转变，技术与商业结合的思维转变。”文景说到。 转型所带来的彷徨并不是所有人都能顺利度过，一度有很多技术人员抱怨业务做太多了，甚至有人离开。文景做为团队负责人，责无旁贷要帮助大家去适应。他当时鼓励工程师们“荤素搭配”自己的工作，要肩负起偏业务性的工作，当然也留出精力去做系统性的纯粹开发，这对工程师的发展是非常有好处的。他也不断地用自己的亲身经历告诉大家，业务，能让技术人员更好地了解产品的设计、提升去场景的理解。阿里全员一直崇尚着“客户第一”，在文景看来，客户第一就是真正地了解客户的需求，再把它变成产品，解决更多客户的问题，而不是你觉得这个产品牛，硬塞给客户去用。总之，技术牛不牛，要拿商业来证明。 到如今，文景所在的阿里云CDN团队已经拥有遍布全球的2500+节点和120T带宽能力储备，同时凭借全球服务能力和产品技术优势被评为全球级（Global）服务商，即面向全球五大洲提供围绕密集商业和消费城市的接入服务。 给年轻技术人一些建议最后，对于想了解或者想踏入CDN这一领域的技术人员，文景也给出了一些建议。 了解行业 CDN这个产品的历史，比云计算还要久，因为互联网的发展而应运而生的产品。现在，这行业是充分竞争的行业，它已经有成熟的解决方案和开源的软件，最终决定性产品的核心竞争力就是：稳定性、成本和质量，厂商们都在寻求更好地突破。阿里云CDN通过历年双11沉淀下来的技术和快速响应能力，已经在四年时间内，从零做到了中国最大的云CDN。未来的CDN行业，会更注重客户价值，面对客户关于低成本、服务质量、安全性、高清视频等不同价值需求点，需要不同场景和技术来满足。 研究开源，专注，不断学习 首先，文景认为去选择优秀的开源软件是一种好的方式，Github是程序员非常好的名片，开源软件写的好的人，代码、沟通能力、落地能力都不会差。第二，一定要专注，决定了方向后，至少要沉淀3年左右的时间，当你成为这个行业的专家，去任何公司都会发挥很大的价值。第三，要不断学习，计算机行业日新月异，对于技术人最大的挑战就是不能停止，要不停去接触新的东西。每年的业务都是两三倍的增长，你会发现你原来的技能已经跟不上业务增长的步伐，在互联网这么快速发展的环境和阿里发展这么迅速的公司，不学习就会被淘汰，绝对不能固步自封。 最后，欢迎加入我们！ 阿里云CDN团队诚招技术人才啦！点此查看最新职位！ 本文作者：山哥在这里阅读原文 本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：当小团队的产出跟不上业务需要，团队就面临规模化的问题。从1个团队到3个团队，仍可以通过简单的团队沟通保持高效协作。当产品复杂到需要5个以上团队同时开发时，我们需要一定的组织设计来保证团队间的顺畅协作，使得多团队共同开发一个产品时仍能保持敏捷性。这时候的组织该如何设计？今天，我们听听阿里敏捷教练怎么说。1、保持小团队在初创企业或产品刚起步时，团队通常都不大。随着业务的发展，需求越来越多，产品越来越复杂，很多团队的第一反应都是加人。事实上，加人并不是唯一选择，也未必是最优选择。很多时候，小团队能交付惊人的业务成果。 一方面，通过保持专注：Do one thing and do it well，小团队可以聚焦于核心业务，摒除不必要的干扰。有一款微处理器 ARM 比英特尔先做出来，团队的一个leader 说：“回过头来看，当时我们决定做一款微处理器的时候，我认为我做了两个重要的决定。我信任我的团队，并且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单”。[2] 类似的，创办于2009年的 WhatsApp 于2014年被 Facebook 收购时，公司只有55名员工，全球活跃用户达到4.5亿人，日发送短消息达160亿条。 另一方面，随着开源运动、中台技术和云化技术的发展，很多非核心业务逻辑可以借助外力快速搭建，在业务高速发展的同时，继续保持一支精干的团队。例如，在阿里巴巴研发协同平台“云效”上，二十分钟就可以搭建一套 Spring Boot web application 的持续集成流水线，包含静态代码扫描、单元测试、编译、打包、部署、接口测试。不仅操作方便快捷，还省去了采购机器、部署和管理 build farm 的开销。 2、业务单元特性团队即便努力保持专注并用尽了技术红利，有时业务的发展还是远远超出预期，此时组建多个团队势在必行。 比较理想的选择是按照业务单元来组建特性团队。一个业务单元类似于一家小型创业公司，有自己的长期使命和愿景，有相对清晰的业务边界和盈利模式。人员方面，各业务单元有独立的业务、产品和研发团队。技术方面，各业务单元可以独立完成产品开发的全流程，包括业务决策、产品设计、开发、测试和发布，尽量避免业务单元之间的依赖。 作为一个超级 app，手机淘宝分为几条业务线，同一条业务线内还分为几个独立业务。例如，微淘和淘宝直播都属于内容平台业务线，二者的内容生产、传播渠道、受众和盈利模式不同，因而是相对独立的业务单元。二者有独立的业务、产品和研发团队，业务目标也分开设定和衡量。 技术上解耦是各业务单元能够独立发展的前提。为了解决团队间的依赖，手机淘宝对架构做了容器化改造：一些必要的初始化操作放在 common 容器中，各业务在自己的 bundle 中。各业务 bundle 按需加载，只能依赖底层的 common 架构，不能相互依赖。这样各业务 bundle 可以并行开发，互不干扰。 按照独立的业务边界来组建特性团队，团队能独立发布新功能，迅速获得市场反馈，通过不断试错找到业务发展的方向。 全球第一大音乐平台、音乐流媒体公司 Spotify 也按照业务单元组建团队。 在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds "[1] ，敏捷教练 Henrik Kniberg 详细介绍了 Spotify 模式。 Spotify 的30多个“小分队”（squad）分布在全球的三个城市，每个 squad 负责产品的特定方向（例如搜索或 radio）。每个 squad 相当于一个小创业公司，squad 没有特定的主管，只有一位产品负责人（Product Owner）。PO 负责业务方向，squad 成员组成跨职能团队交付业务结果。PO 帮助 squad 制定目标和管理优先级，也会定期维护公司层面的产品路线图并确保 squad 的目标与公司战略相匹配。squad被鼓励应用精益创业原则，例如先交付 MVP（minimum viable product），并通过 A/B 测试来验证假设。此外，squad 可以得到敏捷教练的帮助，敏捷教练引导 squad 持续改进并帮助团队移除障碍。 ...

2019年，淘鲜达要在100个城市完成1000个门店的新零售改造。过去一年，初平三分之二的时间在出差，足迹遍及山东、河南、江西、湖南等地。初平是天猫超市事业群战略合作部总经理，负责天猫超市旗下“淘鲜达”战略合作拓展。从2017年年中上线，不到两年时间，已为大润发、欧尚、三江购物等超过700家门店完成新零售升级。2019年年初，淘鲜达制订了拓增100个城市、1000个门店的年度目标。完成了对三江购物胜丰店的秘密改造和试运营后，淘鲜达步入扩张期，其中大润发门店的服务半径已经从现在的3公里扩宽至5公里。拿下三江购物的改造工程过去几年，阿里巴巴孵化盒马鲜生，入股三江购物、新华都、百联集团、大润发和欧尚的母公司高鑫零售等多家实体商超。随着马云在2016年提出新零售，阿里巴巴开始拓宽零售的边界，而生鲜和快消品作为离消费者最近、消费频率最高的品类，成了构筑新业态最好的切入点。淘鲜达业务雏形“淘宝便利店”，就是在这一背景下诞生的，它选在杭州试水。手机淘宝接入实体便利店，周围两公里范围内用手淘下单，货品会在1小时内送到用户手上。“最开始希望拓展阿里巴巴能够做的事情的边界，不可能只是在电商角度去探索，探索线下是为了能够和用户建立更多、更亲密的触点，满足他们之前没有体验过的、新的服务和生活方式。”天猫超市事业群全链路营销部资深运营丝米说。丝米参与过许多淘内创新业务，随后进入“淘宝到家”团队，和无眉搭伙做起淘宝便利店。丝米和无眉先前做的全是线上业务，没有实体零售经验。一开始她们对商家说，“线下店开着可以，但是我帮你在线上再搞一个。”谈判推进慢，好不容易谈下几家，扩展中又发现了问题。“很多是夫妻店，它的运营、服务能力跟不上，教育成本特别高，一家一家做的话，拖到明年、后年也做不了一个城市。这样的夫妻店虽然能够在社区扎根，但很多消费频次其实不是由它们来主要满足的，那些人还是周末会去超市、或者上天猫、淘宝满足 ‘一站式购物’需求。”丝米说。2017年初，“淘宝到家”团队开始接触宁波的三江购物。三江购物此前接入京东到家，它的用户对“到家”模式已经有了认知。考察之后，无眉他们发现，三江购物和京东到家的合作存在痛点。比如很多货品需要临时散称。这带来了几个问题：一是品相不稳定，早晨和下午可挑拣的货品品相差别很大；二是多斤少两没有解决方案，称多了是不是要找消费者补钱？称少了要怎么把钱退回去？三是拣货效率慢，来一单拣一单太慢，还会影响内场消费者体验，另外还要拨出一个收银台，用来摆放几大袋货品，等待配送员取货，这样乱糟糟的场面同样会让人不快……从这些痛点出发，淘鲜达项目正式启动，代号“凤凰”。它不再是简单地为商超提供线上入口，而是重新站在实体商超的角度，思考线上业务如何优化，线上线下如何联动，经营模式如何迭代。于是，单店试运营几个月后，三江购物放弃了京东到家，旗下门店全部接入淘鲜达。淘鲜达的攻坚战将近4个月，无眉常常带队到盒马鲜生，停在一个地方一直看，体会盒马的经验。无眉是天猫超市事业群超市生态事业部区域运营，她当时的角色用一句话形容：“可以理解为除了手淘页面设计和研发我不需要去做，其他的事情我都要去做”。为解决拣货问题，淘鲜达借鉴了盒马店仓一体的设计，把一家实体商超划分为前场和后场，由于没有悬挂链，他们想出了一个人工分拣办法：拣货员按照货架划分，只拣某几个货架的货品，所有货品最后汇总到后场，核批后分配进配送箱，配送员按规划出发。按照这样的办法，拣货员越娴熟，速度越快，同时拣货不再跨区，路径也更短了。另外，淘鲜达还会根据历史数据，对当天热卖商品进行预测，让商超工作人员提前在后场备货。淘鲜达联合三江购物的加工中心推进生鲜标准化，把品质统一、个头差不多的货品事先称重包装，运到后场。交易过程遵循“多退少不补”，钱收多了在线返还用户，收少了用户也无须再补。配送方面，淘鲜达先后接入盒马和蜂鸟，并重新设计了路线规划算法。一方面，为门店分配固定的配送员，摒弃传统的抢单模式；另一方面，淘鲜达把门店的服务范围划分为东南西北四个区域，每个配送员拿到的都是同一个区域的订单，往返时间会因此缩短。“我们不能100%地复制盒马，”无眉说，“是不是再搞一个餐饮区，再加一点灯光，生意就会好？其实并不是，我们不会去做很大的动作。因为，要改变一个品牌在消费者心中的认知是非常难的，做了这种调整，消费者会担心 ‘我在这买东西会不会变贵？’”盒马是“建新城”，淘鲜达是“旧城改造”。无眉说，淘鲜达要专注于那些跟生意本质更相关的着眼点。丝米也说，实体商超“最痛的点”无非是，今天做了淘鲜达，会不会就让线下的生意变少了？淘鲜达放低姿态，倾听线下的想法，并把实质性提升对方营收和盈利作为重心。无眉认为，京东到家只为三江购物“带了一些线上的成交”，没有带来额外的用户。反之，淘鲜达在三江购物装设自助收银机、改造收银系统，实现会员系统线上线下融通，这项改造关键之处是，无论对于淘鲜达，还是三江购物，用户画像都更完整和精准了。“今天，这个消费者在线下买了一瓶飘柔，在线上也买了瓶飘柔，就是这个人，一共买了两瓶，我就知道（是同一个人）了嘛，之前不知道他在线下所有消费习惯。”丝米说。由此，淘鲜达能够获知线下消费者的消费力，比如，“他们会在淘宝上面搜生鲜，然后可能也会搜3C数码，就代表他们的消费层次是高的。”从而，淘鲜达可以通过盒马、云象供应链，为三江购物适时地引入新的货品品类，丰富线下SKU和消费者的体验感。淘鲜达会联合品牌发一些线下优惠券。反之，用户在线下门店买满100元，也能获得一张线上减价券。丝米说，“商家很开心，因为淘鲜达是在帮他提高线下的客单价。”“哪里有阿里，哪里就有灯火”一次一次打磨，淘鲜达和实体商超形成合力，逐渐实现“让最适合的人去最适合的场景里消费”，丝米说，“我们的生活就是由线上和线下组成，消费者在某个点就想买，我们就能让消费行为继续在那个场里面发生下去，以淘鲜达或者线下的能量为他推波助澜，这是我们要做的事情。”无眉依然记得和几个同事在宁波加班到凌晨的日子。时钟划过1点，她穿过马路回到下榻的酒店，透过窗子，看得到对面三江购物的办公室里灯火通明，不禁拍下来，发了一条状态：“哪里有阿里，哪里就有灯火。”2017年5月，三江购物在淘鲜达上线首家门店不久，淘鲜达由手淘并入盒马鲜生。2018年12月，淘鲜达并入天猫超市事业群，“天猫超市、天下超市”成了它的新征程。后来，淘鲜达团队的一名成员把无眉那张在凌晨拍的照片发给盒马鲜生CEO侯毅，“你看，我们团队确实是非常拼的。”本文作者：张文政阅读原文本文来自云栖社区合作伙伴“ 天下网商”，如需转载请联系原作者。

摘要： Scrum等敏捷开发框架，最初都是为5到9人的小团队设计的。通过保持专注和合理利用新技术，在相当长的时间里小团队仍然可以支撑业务发展。 随着业务成长，小团队的产出可能跟不上业务需要，团队就会面临规模化的问题。Scrum等敏捷开发框架，最初都是为5到9人的小团队设计的。通过保持专注和合理利用新技术，在相当长的时间里小团队仍然可以支撑业务发展。随着业务成长，小团队的产出可能跟不上业务需要，团队就会面临规模化的问题。从1个团队拓展到3个团队，仍然可以通过简单的团队间沟通保持高效协作。当产品复杂到需要5个以上团队同时开发时，我们需要一定的组织设计来保证团队间的顺畅协作，使得多团队共同开发一个产品时仍能保持敏捷性。保持小团队在初创企业或产品刚起步时，团队通常都不大。随着业务的发展，需求越来越多，产品越来越复杂，很多团队的第一反应都是加人。事实上，加人并不是唯一选择，也未必是最优选择。很多时候，小团队能交付惊人的业务成果。一方面，通过保持专注：Do one thing and do it well，小团队可以聚焦于核心业务，摒除不必要的干扰。有一款微处理器ARM比英特尔先做出来，团队的一个leader说：“回过头来看，当时我们决定做一款微处理器的时候，我认为我做了两个重要的决定。我信任我的团队，并且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西：第一是缺钱，第二是缺人。他们不得不保持简单”。类似的，创办于2009年的WhatsApp于2014年被Facebook收购时，公司只有55名员工，全球活跃用户达到4.5亿人，日发送短消息达160亿条。另一方面，随着开源运动、中台技术和云化技术的发展，很多非核心业务逻辑可以借助外力快速搭建，在业务高速发展的同时，继续保持一支精干的团队。例如，在阿里巴巴研发协同平台“云效”上，二十分钟就可以搭建一套Spring Boot web application的持续集成流水线，包含静态代码扫描、单元测试、编译、打包、部署、接口测试。不仅操作方便快捷，还省去了采购机器、部署和管理 build farm的开销。业务单元特性团队即便努力保持专注并用尽了技术红利，有时业务的发展还是远远超出预期，此时组建多个团队势在必行。比较理想的选择是按照业务单元来组建特性团队。一个业务单元类似于一家小型创业公司，有自己的长期使命和愿景，有相对清晰的业务边界和盈利模式。人员方面，各业务单元有独立的业务、产品和研发团队。技术方面，各业务单元可以独立完成产品开发的全流程，包括业务决策、产品设计、开发、测试和发布，尽量避免业务单元之间的依赖。作为一个超级app，手机淘宝分为几条业务线，同一条业务线内还分为几个独立业务。例如，微淘和淘宝直播都属于内容平台业务线，二者的内容生产、传播渠道、受众和盈利模式不同，因而是相对独立的业务单元。二者有独立的业务、产品和研发团队，业务目标也分开设定和衡量。技术上解耦是各业务单元能够独立发展的前提。为了解决团队间的依赖，手机淘宝对架构做了容器化改造：一些必要的初始化操作放在common容器中，各业务在自己的bundle中。各业务bundle按需加载，只能依赖底层的common架构，不能相互依赖。这样各业务bundle可以并行开发，互不干扰。按照独立的业务边界来组建特性团队，团队能独立发布新功能，迅速获得市场反馈，通过不断试错找到业务发展的方向。全球第一大音乐平台、音乐流媒体公司Spotify也按照业务单元组建团队。在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds “[1] ，敏捷教练Henrik Kniberg详细介绍了Spotify模式。Spotify的30多个“小分队”（squad）分布在全球的三个城市，每个squad负责产品的特定方向（例如搜索或radio）。每个squad相当于一个小创业公司，squad没有特定的主管，只有一位产品负责人（Product Owner）。PO负责业务方向，squad成员组成跨职能团队交付业务结果。PO帮助squad制定目标和管理优先级，也会定期维护公司层面的产品路线图并确保squad的目标与公司战略相匹配。squad被鼓励应用精益创业原则，例如先交付MVP（minimum viable product），并通过A/B测试来验证假设。此外，squad可以得到敏捷教练的帮助，敏捷教练引导squad持续改进并帮助团队移除障碍。在squad之上，spotify还有两层组织架构：具有相关专业知识的人横向组成“分会”（chapter），工作在相似领域的squad组成“部落”（tribe）。此外，具有相同兴趣的人组成“行会”（guild）。这套架构的主要目的，是促进全公司范围的信息和知识共享。员工向chapter lead汇报，在转换squad时汇报线不变。尽管看上去像普通的矩阵式组织，这个矩阵是向产品交付倾斜的。同一个squad的成员坐在一起，组成高度自治的跨职能敏捷团队，共同决定产品目标以及如何交付产品。横向的chapter维度只是为了更方便地共享知识、工具和代码。chapter lead的工作是引导和支持信息流动和知识共享，而不会像传统职能经理那样负责分配工作。注：图片来自于https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify与此类似，淘宝直播的业务、产品和研发团队也汇报给不同的职能经理。高度统一的业务目标把团队成员凝聚在一起，团队共同决定业务方向、业务目标以及如何达成目标。职能经理为业务发展提供支持和帮助，并帮助团队成员在职业道路上成长，并不会把主要精力放在具体的产品交付上。淘宝直播敏捷实践参见《阿里敏捷教练，全面解析淘宝直播敏捷实践之路》。无限制特性团队有时团队在业务发展时壮大了，但是经过了一段高速发展，原有的业务方向遇到了瓶颈，新的业务方向还在摸索中。此时，业务方向还不明朗，难以按照明确的业务单元组建团队，团队需要快速适应业务方向的变化。此时，要鼓励团队广度学习，避免局部优化。不同于围绕业务单元组建的特性团队，无限制特性团队没有相对独立的业务领域，多个特性团队共享一份产品代办列表（Product Backlog），按照统一的优先级交付产品功能。无限制特性团队，并非所有团队都相同的无差别特性团队，每个团队还是可以有自己的特色和专长，只要多个团队组合起来能够按照Product Backlog的优先级交付特性即可。2018年3月，我支持阿里健康互联网医疗业务线时，正遇到这样的情况：互联网医疗业务经过两年多的摸索，找到了一些可能的发展方向，但是还没有找到非常明确的盈利模式，多个方向都需要进一步尝试。研发团队包括服务端开发、H5开发、Android开发、iOS开发、测试等30多位同学。在原有的资源池模式下，每月职能经理按照产品经理的输入，分配研发同学到各个项目中。由于业务的复杂性，产品涉及的核心应用有15个以上，除了电商平台的商品、库存、营销等基本功能，还包含互联网医疗特有的问诊、挂号等服务，并涉及到算法和AI。人员技能的瓶颈非常突出：部分核心应用只有一位同学特别了解。2018年4月至5月，商品模块负责人和AI问诊模块负责人先后休假，相应模块的技术方案设计几乎停滞，严重拖累进度。为了平衡复杂的人员技能和项目需要，职能经理经常绞尽脑汁，仍然不免捉襟见肘，一线同学身兼多个项目非常普遍。多个项目都依赖同一位团队成员时，不得不串行等待。在多个项目间频繁切换也增加了上下文切换成本。为了解决人员技能瓶颈的痛点，同时考虑到互联网医疗特定的业务发展阶段，尝试了无限制特性团队共同交付一个产品的协作模式：30人自由组合成两支特性团队。组队只需满足约束条件：人数均衡，核心应用在每个团队都有人了解，新老结合，男女搭配。组队成功后，两支团队从同一份Product Backlog里按照优先级领需求。如果某个团队无法独立完成当前最高优先级的需求，先由这个团队认领，另一个团队派师傅指导。师傅主要是培养徒弟，具体工作由认领团队的同学动手完成。由于资源瓶颈的限制，2018年5月1日到6月14日需求交付的累计偏差（需求实际交付日期与计划交付日期的偏差累加）达到了151天。经过两个月的努力，两支特性团队都具备了完成各类需求的能力，团队可以完全按照Product Backlog的优先级领需求，既不需要团队成员并发支持多个项目，也不需要等待资源瓶颈的释放。6月15日到7月31日的累计交付偏差缩短到了3天。8月1日到8月31日继续保持准时交付，累计交付偏差为2天。团队成员的个人能力得到了充分锻炼，主动拓展技能承担重任的同学获得了晋升，得到了认可。团队的自组织能力也得到了发展，遇到问题和阻碍，团队成员会主动想办法解决，不再事事依赖职能经理。职能经理的角色从派活变成了辅导和帮助团队，减少了救火时间，有更多时间考虑团队的长远发展。综上，无限制特性团队方案解决了业务需求等待资源瓶颈的痛点，不是让业务发展来匹配人员的技能，而是人员拓展技能匹配业务发展的需要。与此同时，团队成员的个人能力得到了锻炼，团队的自组织能力得到了发展，也解放了职能经理。无论是业务单元特性团队，还是无限制特性团队，每个团队都要具有独立交付产品特性的能力。一个复杂的产品特性，通常都需要修改多个模块才能实现。多个团队修改同一个模块时，如何保证模块设计的一致性，并及时清理代码偿还技术债？引入模块守护者通常是个有益的实践：每个模块最好有两位模块守护者互相backup，修改模块代码需要请模块守护者做code review，一些复杂的修改最好预先进行设计评审。模块守护者可以是兼职的，只要保证每周抽出一定比例的时间维护模块代码即可。随着业务方向越来越清晰，业务模式逐渐稳定，无限制特性团队会逐步找到相对固定的分工合作模式，每个特性团队会逐步找到自己最擅长和最感兴趣的产品方向。明确的产品方向，为团队提供了长期深耕的条件，团队逐步成为某一领域的专家。此时，无限制特性团队就完成了向业务单元特性团队的过渡。小结通过手机淘宝、Spotify和阿里健康的案例，我相信多团队开发一个产品仍然可以保持敏捷。在业务方向明确的情况下，按照业务单元组建特性团队是最理想的选择。在业务方向不明朗的情况下，可以先组建无限制特性团队，再逐步过渡到业务单元特性团队。无论采用何种组织设计，目的都是快速跑通业务闭环：持续地交付业务价值，并在真正的市场环境中检验假设，通过快速试错找到在一定的利润水平上为企业或终端用户提供产品和服务的可行方法。参考文献：[1] https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify作者：张迎辉，花名问菊，阿里巴巴敏捷教练，罗汉堂讲师，开发和讲授多门敏捷课程。先后支持手机淘宝、优酷、阿里文娱广告、阿里健康等多个部门的团队敏捷转型。亲身感受到敏捷给团队带来的改变，立志成为敏捷践行者.阅读作者更多内容：阿里敏捷教练，全面解析淘宝直播敏捷实践之路敏捷团队的病与药——阿里健康B2B团队敏捷转型手记打造真正的One Team，持续快速交付价值——阿里文娱广告团队敏捷实践阿里敏捷教练如何优化优酷需求分析流程？本文作者：云效鼓励师阅读原文本文为云栖社区原创内容，未经允许不得转载。

简介上一个博文已经讲述了如何使用selenium跳过webdriver检测并爬取天猫商品数据，所以在此不再详细讲，有需要思路的可以查看另外一篇博文。源代码 # -- coding: utf-8 --from selenium import webdriverfrom selenium.webdriver.common.by import Byfrom selenium.webdriver.support.ui import WebDriverWaitfrom selenium.webdriver.support import expected_conditions as ECfrom pyquery import PyQuery as pqfrom time import sleepimport random#定义一个taobao类class taobao_infos: #对象初始化 def init(self): url = ‘https://login.taobao.com/member/login.jhtml' self.url = url options = webdriver.ChromeOptions() options.add_experimental_option(“prefs”, {“profile.managed_default_content_settings.images”: 2}) # 不加载图片,加快访问速度 options.add_experimental_option(’excludeSwitches’, [’enable-automation’]) # 此步骤很重要，设置为开发者模式，防止被各大网站识别出来使用了Selenium self.browser = webdriver.Chrome(executable_path=chromedriver_path, options=options) self.wait = WebDriverWait(self.browser, 10) #超时时长为10s #登录淘宝 def login(self): # 打开网页 self.browser.get(self.url) # 自适应等待，点击密码登录选项 self.browser.implicitly_wait(30) #智能等待，直到网页加载完毕，最长等待时间为30s self.browser.find_element_by_xpath(’//[@class=“forget-pwd J_Quick2Static”]’).click() # 自适应等待，点击微博登录宣传 self.browser.implicitly_wait(30) self.browser.find_element_by_xpath(’//[@class=“weibo-login”]’).click() # 自适应等待，输入微博账号 self.browser.implicitly_wait(30) self.browser.find_element_by_name(‘username’).send_keys(weibo_username) # 自适应等待，输入微博密码 self.browser.implicitly_wait(30) self.browser.find_element_by_name(‘password’).send_keys(weibo_password) # 自适应等待，点击确认登录按钮 self.browser.implicitly_wait(30) self.browser.find_element_by_xpath(’//[@class=“btn_tip”]/a/span’).click() # 直到获取到淘宝会员昵称才能确定是登录成功 taobao_name = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘.site-nav-bd > ul.site-nav-bd-l > li#J_SiteNavLogin > div.site-nav-menu-hd > div.site-nav-user > a.site-nav-login-info-nick ‘))) # 输出淘宝昵称 print(taobao_name.text) # 模拟向下滑动浏览 def swipe_down(self,second): for i in range(int(second/0.1)): #根据i的值，模拟上下滑动 if(i%2==0): js = “var q=document.documentElement.scrollTop=” + str(300+400i) else: js = “var q=document.documentElement.scrollTop=” + str(200 * i) self.browser.execute_script(js) sleep(0.1) js = “var q=document.documentElement.scrollTop=100000” self.browser.execute_script(js) sleep(0.1) # 爬取淘宝 我已买到的宝贝商品数据 def crawl_good_buy_data(self): # 对我已买到的宝贝商品数据进行爬虫 self.browser.get(“https://buyertrade.taobao.com/trade/itemlist/list_bought_items.htm") # 遍历所有页数 for page in range(1,1000): # 等待该页面全部已买到的宝贝商品数据加载完毕 good_total = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘#tp-bought-root > div.js-order-container’))) # 获取本页面源代码 html = self.browser.page_source # pq模块解析网页源代码 doc = pq(html) # # 存储该页已经买到的宝贝数据 good_items = doc(’#tp-bought-root .js-order-container’).items() # 遍历该页的所有宝贝 for item in good_items: good_time_and_id = item.find(’.bought-wrapper-mod__head-info-cell___29cDO’).text().replace(’\n’,”").replace(’\r’,"") good_merchant = item.find(’.seller-mod__container___1w0Cx’).text().replace(’\n’,"").replace(’\r’,"") good_name = item.find(’.sol-mod__no-br___1PwLO’).text().replace(’\n’, “”).replace(’\r’, “”) # 只列出商品购买时间、订单号、商家名称、商品名称 # 其余的请自己实践获取 print(good_time_and_id, good_merchant, good_name) print(’\n\n’) # 大部分人被检测为机器人就是因为进一步模拟人工操作 # 模拟人工向下浏览商品，即进行模拟下滑操作，防止被识别出是机器人 # 随机滑动延时时间 swipe_time = random.randint(1, 3) self.swipe_down(swipe_time) # 等待下一页按钮 出现 good_total = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘.pagination-next’))) # 点击下一页按钮 good_total.click() sleep(2)if name == “main”: # 使用之前请先查看当前目录下的使用说明文件README.MD # 使用之前请先查看当前目录下的使用说明文件README.MD # 使用之前请先查看当前目录下的使用说明文件README.MD chromedriver_path = “/Users/bird/Desktop/chromedriver.exe” #改成你的chromedriver的完整路径地址 weibo_username = “改成你的微博账号” #改成你的微博账号 weibo_password = “改成你的微博密码” #改成你的微博密码 a = taobao_infos() a.login() #登录 a.crawl_good_buy_data() #爬取淘宝 我已买到的宝贝商品数据 使用教程点击这里下载下载chrome浏览器查看chrome浏览器的版本号，点击这里下载对应版本号的chromedriver驱动pip安装下列包[x] pip install selenium点击这里登录微博，并通过微博绑定淘宝账号密码在main中填写chromedriver的绝对路径在main中填写微博账号密码 #改成你的chromedriver的完整路径地址 chromedriver_path = “/Users/bird/Desktop/chromedriver.exe” #改成你的微博账号 weibo_username = “改成你的微博账号” #改成你的微博密码 weibo_password = “改成你的微博密码” 演示图片爬虫过程图片查看不了点击这里爬虫结果图片查看不了点击这里其他爬虫源代码所有关于爬虫的项目都放在github了，有需要的可以去GitHub仓库项目持续更新，欢迎您star本项目 ...

简介模拟登录淘宝已经不是一件新鲜的事情了，过去我曾经使用get/post方式进行爬虫，同时也加入IP代理池进行跳过检验，但随着大型网站的升级，采取该策略比较难实现了。因为你使用get/post方式进行爬取数据，会提示需要登录，而登录又是一大难题，需要滑动验证码验证。当你想使用IP代理池进行跳过检验时，发现登录时需要手机短信验证码验证，由此可以知道旧的全自动爬取数据对于大型网站比较困难了。selenium是一款优秀的WEB自动化测试工具，所以现在采用selenium进行半自动化爬取数据，支持模拟登录淘宝和自动处理滑动验证码。编写思路由于现在大型网站对selenium工具进行检测，若检测到selenium，则判定为机器人，访问被拒绝。所以第一步是要防止被检测出为机器人，如何防止被检测到呢？当使用selenium进行自动化操作时，在chrome浏览器中的consloe中输入windows.navigator.webdriver会发现结果为Ture，而正常使用浏览器的时候该值为False。所以我们将windows.navigator.webdriver进行屏蔽。在代码中添加： options = webdriver.ChromeOptions() # 此步骤很重要，设置为开发者模式，防止被各大网站识别出来使用了Selenium options.add_experimental_option(’excludeSwitches’, [’enable-automation’]) self.browser = webdriver.Chrome(executable_path=chromedriver_path, options=options)同时，为了加快爬取速度，我们将浏览器模式设置为不加载图片，在代码中添加： options = webdriver.ChromeOptions() # 不加载图片,加快访问速度 options.add_experimental_option(“prefs”, {“profile.managed_default_content_settings.images”: 2}) 至此，关键的步骤我们已经懂了，剩下的就是编写代码的事情了。在给定的例子中，需要你对html、css有一定了解。比如存在以下代码： self.browser.find_element_by_xpath(’//[@class=“btn_tip”]/a/span’).click() taobao_name = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘.site-nav-bd > ul.site-nav-bd-l > li#J_SiteNavLogin > div.site-nav-menu-hd > div.site-nav-user > a.site-nav-login-info-nick ‘))) print(taobao_name.text)第1行代码指的是从根目录(//)开始寻找任意()一个class名为btn_tip的元素，并找到btn_tip的子元素a标签中的子元素span第2行代码指的是等待某个CSS元素出现，否则代码停留在这里一直检测。以.开头的在CSS中表示类名(class)，以#开头的在CSS中表示ID名(id)。A > B，指的是A的子元素B。所以这行代码可以理解为寻找A的子元素B的子元素C的子元素D的子元素E出现，否则一直在这里检测。第3行代码指的是打印某个元素的文本内容使用教程点击这里下载下载chrome浏览器查看chrome浏览器的版本号，点击这里下载对应版本号的chromedriver驱动pip安装下列包[x] pip install selenium点击这里登录微博，并通过微博绑定淘宝账号密码在main中填写chromedriver的绝对路径在main中填写微博账号密码 #改成你的chromedriver的完整路径地址 chromedriver_path = “/Users/bird/Desktop/chromedriver.exe” #改成你的微博账号 weibo_username = “改成你的微博账号” #改成你的微博密码 weibo_password = “改成你的微博密码” 演示图片图片查看不了点击这里源代码项目源代码在GitHub仓库项目持续更新，欢迎您star本项目

简介现在爬取淘宝，天猫商品数据都是需要首先进行登录的。上一节我们已经完成了模拟登录淘宝的步骤，所以在此不详细讲如何模拟登录淘宝。把关键点放在如何爬取天猫商品数据上。过去我曾经使用get/post方式进行爬虫，同时也加入IP代理池进行跳过检验，但随着大型网站的升级，采取该策略比较难实现了。因为你使用get/post方式进行爬取数据，会提示需要登录，而登录又是一大难题，需要滑动验证码验证。当你想使用IP代理池进行跳过检验时，发现登录时需要手机短信验证码验证，由此可以知道旧的全自动爬取数据对于大型网站比较困难了(小型网站可以使用get/post，没检测或者检测系数较低)。selenium是一款优秀的WEB自动化测试工具，所以现在采用selenium进行半自动化爬取数据。编写思路由于现在大型网站对selenium工具进行检测，若检测到selenium，则判定为机器人，访问被拒绝。所以第一步是要防止被检测出为机器人，如何防止被检测到呢？当使用selenium进行自动化操作时，在chrome浏览器中的consloe中输入windows.navigator.webdriver会发现结果为Ture，而正常使用浏览器的时候该值为False。所以我们将windows.navigator.webdriver进行屏蔽。在代码中添加： options = webdriver.ChromeOptions() # 此步骤很重要，设置为开发者模式，防止被各大网站识别出来使用了Selenium options.add_experimental_option(’excludeSwitches’, [’enable-automation’]) self.browser = webdriver.Chrome(executable_path=chromedriver_path, options=options)同时，为了加快爬取速度，我们将浏览器模式设置为不加载图片，在代码中添加： options = webdriver.ChromeOptions() # 不加载图片,加快访问速度 options.add_experimental_option(“prefs”, {“profile.managed_default_content_settings.images”: 2}) 同时，为了模拟人工操作，我们在浏览网页的时候，模拟下滑，插入代码： # 模拟向下滑动浏览 def swipe_down(self,second): for i in range(int(second/0.1)): js = “var q=document.documentElement.scrollTop=” + str(300+200i) self.browser.execute_script(js) sleep(0.1) js = “var q=document.documentElement.scrollTop=100000” self.browser.execute_script(js) sleep(0.2)至此，关键的步骤我们已经懂了，剩下的就是编写代码的事情了。在给定的例子中，需要你对html、css有一定了解。比如存在以下代码： self.browser.find_element_by_xpath(’//[@class=“btn_tip”]/a/span’).click() taobao_name = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘.site-nav-bd > ul.site-nav-bd-l > li#J_SiteNavLogin > div.site-nav-menu-hd > div.site-nav-user > a.site-nav-login-info-nick ‘))) print(taobao_name.text)第1行代码指的是从根目录(//)开始寻找任意(*)一个class名为btn_tip的元素，并找到btn_tip的子元素a标签中的子元素span第2行代码指的是等待某个CSS元素出现，否则代码停留在这里一直检测。以.开头的在CSS中表示类名(class)，以#开头的在CSS中表示ID名(id)。A > B，指的是A的子元素B。所以这行代码可以理解为寻找A的子元素B的子元素C的子元素D的子元素E出现，否则一直在这里检测。第3行代码指的是打印某个元素的文本内容看完上面的代码，我们大概了解了selenium中html、css的基本规则。我们来实践一下，在搜索商品的时候如何检测一共有多少页呢？不妨看看以下代码： # 等待该页面全部商品数据加载完毕 good_total = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘#J_ItemList > div.product > div.product-iWrap’))) # 等待该页面input输入框加载完毕 input = self.wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ‘.ui-page > div.ui-page-wrap > b.ui-page-skip > form > input.ui-page-skipTo’))) # 获取当前页 now_page = input.get_attribute(‘value’) print(“当前页数” + now_page + “,总共页数” + page_total)打开chrome中的控制台，转向console。点击console面板中的十字指针，移动到网页中的“共31页，到第1页”，然后点击。你就可以看到该元素的class名为ui-page-skipTo，由于在css中，class用.表示，所以代码为.ui-page-skipTo。同时由于他的类型是input输入框，变成input.ui-page-skipTo。那么是否可以把代码直接写成.ui-page-skipTo呢？答案是不一定，如果这个元素在网页中是唯一的，没有其他的input的名字也叫ui-page-skipTo的话，就可以。所以，为了保证代码健壮性，我们从他的父元素一直查找，直到我们觉得那个父元素是唯一的，那么这样查找到的元素就是唯一的了。所以最终查找到的结果为.ui-page > div.ui-page-wrap > b.ui-page-skip > form > input.ui-page-skipTo最后，我们获取这个Input的值，代码为input.get_attribute(‘value’)在获取商品数据中，存在以下代码： # 获取本页面源代码 html = self.browser.page_source # pq模块解析网页源代码 doc = pq(html) # 存储天猫商品数据 good_items = doc(’#J_ItemList .product’).items() # 遍历该页的所有商品 for item in good_items: good_title = item.find(’.productTitle’).text().replace(’\n’,"").replace(’\r’,"") good_status = item.find(’.productStatus’).text().replace(" “,”").replace(“笔”,"").replace(’\n’,"").replace(’\r’,"") good_price = item.find(’.productPrice’).text().replace("¥", “”).replace(" “, “”).replace(’\n’, “”).replace(’\r’, “”) good_url = item.find(’.productImg’).attr(‘href’) print(good_title + " " + good_status + " " + good_price + " " + good_url + ‘\n’)首先，我们获取本页面的源代码html = self.browser.page_source，然后用pq模块对源代码进行格式化解析doc = pq(html)，通过上面的讲解，我们已经学会了如何分析css元素了。你会发现有一个DIV元素包含着所有商品元素，他的ID(不是class哦)为J_ItemList，所以代码为#J_ItemList，由于我们要获取的是每一个商品，所以代码为#J_ItemList .product，这样就可以获取所有class名为product的元素啦。接着对每个商品元素进行分析，后面的就不必详细说了。replace函数是对文本进行一些基本替换。使用教程点击这里下载下载chrome浏览器查看chrome浏览器的版本号，点击这里下载对应版本号的chromedriver驱动pip安装下列包[x] pip install selenium点击这里登录微博，并通过微博绑定淘宝账号密码在main中填写chromedriver的绝对路径在main中填写微博账号密码 #改成你的chromedriver的完整路径地址 chromedriver_path = “/Users/bird/Desktop/chromedriver.exe” #改成你的微博账号 weibo_username = “改成你的微博账号” #改成你的微博密码 weibo_password = “改成你的微博密码” 演示图片爬虫过程图片查看不了点击这里爬虫结果图片查看不了点击这里源代码项目源代码在GitHub仓库项目持续更新，欢迎您star本项目 ...

导读：本文是阿里云RPA（机器人流程自动化）干货系列之二，主要介绍了RPA的发展齐纳经和主要使用场景有哪些，目前国内外主流的RPA厂商以及RPA的未来在哪。一、RPA的发展前景根据Gartner的最新研究，2018年全球机器人流程自动化（RPA）软件的开支预计将达到6.8亿美元，同比增长57％，到2022年支出达到24亿美元。Gartner副总裁CathyTornbohm表示：“最终用户组织把RPA技术作为手动任务自动化的一种快速简便的方法。一些员工将继续执行那些要求他们手动剪切、粘贴和更改数据的日常任务。但是当RPA工具执行这些操作时，误差率会降低，数据质量会提高。”如今，RPA最主要的应用领域包括电商、财务/税务、银行、制造业、新零售、保险、物流、政府、公安等各行各业。Tornbohm表示：“通常，这些组织很难将财务和HR系统等不同元素结合在一起，他们正在转向采用RPA解决方案，实现现有的手动任务或流程的自动化，或者传统系统功能的自动化。”RPA工具结合使用多种用户界面交互描述技术，模仿人类工作者完成任务所去采取的“手动”路径。目前试产各种有广泛的解决方案，有很多工具可以在单个台式机或企业服务器上运行。Gartner估计，到2018年年底60％收入超过10亿美元的企业组织将部署RPA工具。到2022年底，85％的大型和超大型组织将部署某种形式的RPA。Tornbohm表示：“到2019年，随着采用率的提高，以及企业组织系统通过该技术实现更好的业务成果，例如降低成本、提高准确性、提高合规性，RPA的平均价格会下降10％至15％。”二、RPA的应用领域有哪些？目前的国内外RPA技术的应用已经日趋成熟，该技术的应用可让企业员工通过开发RPA机器人应用来捕获现有应用程序处理交易，操纵数据，与其他信息系统进行通信等，任何采用大规模人力执行的大量重复性工作，现在都可以由RPA机器人代劳，节省人力、金钱和时间。正如工业机器人是由创造更高的生产率和质量来提高和改造制造业，RPA机器人正在彻底改变我们对管理业务流程的认知，包括业务流程、工作流程、远程基础架构和后台的工作方式，显著改善工作的精确度和周期时间，并提高在企业事务处理上的生产效率。RPA的应用场景需要符合两大要点：大量重复（让RPA有必要）、规则明确（让RPA有可能）。在此基础上，RPA软件机器人可以应用于任何行业和业务场景，例如：应用于财务领域，RPA=财务机器人，用来实现财务处理自动化；应用于税务领域，RPA=税务机器人，用来实现税务处理自动化；应用于政府部门，RPA=政务机器人，用来实现政务处理自动化；应用于保险领域，RPA=保险机器人，用来实现保险业务自动化；应用于医疗领域，RPA=医疗机器人，用来实现医院业务自动化；应用于银行领域，RPA=银行机器人，用来实现银行业务自动化；应用于物流领域，RPA=物流机器人，用来实现物流业务自动化；应用于供应链，RPA=供应链机器人，用来实现供应链管理自动化；应用于销售链，RPA=销售链机器人，用来实现销售链管理自动化；应用于HR，RPA=HR机器人，用来实现企业人力资源管理自动化；应用于IT，RPA=IT机器人，用来实现企业IT工作自动化；等等三、国内外主流RPA厂商1）Blue prismBlue Prism（简称BP）是RPA领域的先行者，机器人流程自动化（RPA）这个术语就是由Blue Prism率先提出的。公司成立于2001年，是一家英国跨国软件公司，Blue Prism已经得到美国IT研究和咨询公司Gartner的认可，他们已经在全球拥有超过200个客户，并与NHS、埃森哲、Hexaware、Hewlett Packard Enterprise、Capgemini、IBM等大型巨头合作。目前Blue Prism产品已经更新到V6版本，正在和最新的人工智能产品进行不断整合和吸收。2）UipathUiPath是一家成立于2005年的全球软件公司，致力于开发机器人流程自动化（RPA）平台，是RPA领域的独角兽，他们与SAP、安永（EY）、J.P.Morgan、德勤（Deloitte）、埃森哲（Accenture）、凯捷（Capgemini）、BBC等公司已有合作关系。以下是UiPath提供的3个机器人过程自动化产品:UiPath StudioUiPath RobotsUiPath Orchestrator3）Automation AnywhereAutomation Anywhere（简称AA）是目前很强大、用户范围最大的RPA供应商，提供强大的、用户友好的RPA工具去处理复杂的任务。他们与EMC2、毕马威（KPMG）,德勤（Deloitte）、埃森哲（Accenture）、 简柏特（Genpact）、印孚瑟斯（Infosys） 等公司合作。2017年7月IBM和Automation Anywhere宣布合作，助力企业简化运营，将交付IBM RPA和BPM。4）NICENICE是RPA业内领先的解决方案提供商，也有一些成功的案例。在NICE的官网上，有很多的白皮书及高质量的与RPA相关的博客，可以通过这些电子资料，了解更多干预机器人流程自动化相关的业务和案例。5）WorkFusionWorkFusion是一家致力于开发人工智能软件产品来改造工作的软件公司。公司总部位于纽约华尔街，在印度、美国和欧洲设有分支机构。主要的业务就是机器人流程自动化、人工智能和认知自动化。6）艺赛旗成立于2011年，总部位于上海，是一家做机器人流程自动化iS-RPA( i-Search Robotic Process Automation)产品、UEBA（User and Entity Behavior Analytics）和双录系统解决方案（CSM：Counter Service Monitor）的软件厂商，为客户提供企业内部数据跨平台整合、云安全管理、大数据安全分析、用户行为收集分析、应用操作录屏审计、客服行为可视化质检、银行柜面交易监控及分析。7）阿里云RPA2011年诞生于阿里巴巴集团淘宝平台，普遍赋能集团内部，如天猫、淘宝、飞猪、集团财务、菜鸟、蚂蚁金服等，曾经获得淘宝年度创新奖和集团特殊贡献奖。2016年正式上线后，已为电商、金融、制造、政务等多个领域输出行业解决方案，平均提高效能500%。目前阿里云RPA发布了3.0版本，采用python开发引擎，拥有强大的控件录制功能、丰富的SDK能力以及更私密的数据安全措施，并且在与Office相关的控件上有自己独特的优势。四、RPA的未来都说“未来已来”，RPA作为一种软件机器人，既然是“人”，那么就应该有眼睛、耳朵、嘴巴、有手，有脑袋，利用人工智能领域目前相对成熟的技术，RPA机器人就具有了类似于人的这些功能：眼睛，利用OCR、图像识别、语义识别等技术，RPA机器人可以“阅读”打印和手写的文字，实现例如发票识别，身份证识别，银行卡识别等功能，在过去两年我的团队已经开发了利用Google OCR和微软认知服务实现图像识别和文字识别功能。耳朵，利用语音识别技术，RPA机器人可以“听懂”人类对话，结合语义识别技术就可以实现例如会议记录（文字），实时翻译等功能，目前我的团队已经开发了利用微软认知服务实现语音识别和实时翻译的功能。嘴巴，利用语音合成技术，RPA机器人可以“说话”，结合语音识别和语义识别技术就可以实现例如职能导游，智能导购，智能Help Desk服务等功能；在2017年我的团队开发了一款Office机器人，具有声音提醒功能；手脚，利用机器手臂、自动驾驶等技术，RPA机器人可以“行动”，结合机器学习等技术就可以实现例如无人驾驶，无人物流，无人工厂等；同上，在2017年我的团队开发了一款Office机器人，具有在桌面上移动、转动头部和手臂的功能；脑袋，利用统计分析、机器学习等人工智能技术，RPA机器人就真正具有了智能可以像人一样“思考、学习和决策”。目前这些单项的技术已经相对成熟了，RPA可以将这些散落的珍珠串成美丽的项链，以客户可以承受的价格戴在企业的脖子上，使其以更加优雅的姿态参与到日益严酷的市场竞争中去，占据先机，成就未来。在Gartner公布的2018年人工智能技术成熟度曲线中，RPA工具目前位于膨胀期望的峰值，企业组织寻求利用RPA削减成本、连接传统应用、以及实现高投资回报率。但是，实现强大投资回报率的潜力完全取决于RPA是否符合个别组织的需求。“在短期内，我们预计会有越来越多的RPA厂商以及软件厂商越来越感兴趣，其中包括希望从这些功能中获得收益的软件测试厂商和业务流程管理厂商。”此外，另一个市场趋势正在出现：将人工智能功能集成到产品套件中，这是因为RPA提供商添加或集成了机器学习和AI技术，以提供更多类型的自动化。本文作者：琰珉阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 支付宝与欲望、想象力的博弈乃至搏斗，10年来不曾停歇。小蚂蚁说：双11十年间，交易规模的指数级增长不断挑战人们的想象力，而对蚂蚁技术团队来说，这不仅是一场消费盛宴，而是无数次濒临压力和焦虑极限的体验，更是技术的练兵场。如今双11对蚂蚁金服而言，已经绝不仅限于一个技术项目，而更像是一个社会化工程，可以叫做「连贯的，社会化的技术大协作」。支付宝团队不正像那尊红漆雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。「双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的消费前端感受到一些使用体验的卡顿、不舒适，而内里则是这批工程师与欲望、想象力的博弈乃至搏斗，并在很多个逼近焦虑极限的瞬间，不断打破桎梏。「为了几十秒，值吗？」杭州入秋的早晨，凉得很，黄勇（花名展一）起个大早，跟几位同事结伴跑了趟灵隐寺。这千年古刹在深山，向来香火旺盛。这几年，寺庙时兴环保，免费发清香，他请了三炷，点上，拜拜。采访时，我问拜的哪位菩萨，黄勇皱皱眉头，乐了，「还真不认识」。烧香的心可是诚的，况且，来许愿的人，没几个比他的愿望还大，作为今年双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对蚂蚁金服来说，已经绝不仅限于一个技术项目，而更像是一个社会化工程。程立说，如果为它定义一个清晰的组织概念，可以叫做「连贯的，社会化的技术大协作」。一面敬畏，一面狂奔蚂蚁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年年末，西班牙《世界报》刊文表达了对中国支付产业的看法，给出的结论叫做：「中国的支付革命堪称中国史上最大的技术革新之一。」技术的价值观其实从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点一过。对支付技术来说，稳定压倒一切，稳定也意味着一切。一如往年，第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%的互联网金融企业，它正在被深深影响、驱动并改变着，企业里大量人、事、物，都在明确地呈现这这种趋势导向，这家价值上千亿美金的企业，也正在成为一个由技术价值观驱动业务、团队革新与发展的经典范本。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 智能监控是智能运维的子领域，详细分析。作者简介王肇刚：阿里巴巴全球运行指挥中心高级技术专家智能监控是智能运维的子领域，我们说的监控，探讨的更多是在监控策略，因为可能从数据采集、日志收集、包括计算等等产生数据，再设定一些判断的规则和策略，发送报警，这些都属于监控。我和我的团队在阿里内部的分工是横向去看阿里巴巴业务指标的监控，我们就以这个话题展开。分享分为五个环节，从阿里巴巴不同的业态，特别是新的业态带来的挑战讲起。对于我们之前已有的基于机器学习算法这样一个算法工程架构，我们做了哪些增强应对这些挑战。我们的监控也从单一指标监控延展到多个指标一起监控。监控完了之后，我们可能要分析定位，这时系统又能帮运维工程师做什么，这是第四方面的话题。最后是对智能运维整个领域做一些展望。一、新业态给业务监控带来的挑战上图是阿里巴巴不同的业态，有比较传统的电商业态，右上角是国际电商，蚂蚁金服还有阿里云。最近这段时间阿里在收购各种各样的公司，也是商业的布局，我们会看到优酷、钉钉等等。我们团队在阿里巴巴内部是负责横向的业务指标监控，这个有什么差异？技术层面也是通过日志的采集流程计算看一个指标下跌还是上涨，区别在于只要业务发生了不可用或者发生问题，我们希望都能够发现，而不是说阿里巴巴本身的系统出问题了。举个例子，如果阿里巴巴一点异常都没有，但是电信可能有问题，这个时候我们希望知道。它是从对于业务数据量实时的监控。因为阿里巴巴本身的业态是很丰富的，有这么多的业态，我们看到的数据也很丰富。上边这个图，大家可能看到的这些 Logo，看到购物或云计算的一些业务，但是团队做智能运维算法的同学，看到的就是右边这种奇形怪状的曲线。我们团队在阿里内部是横向团队，第一环节就是需要能够精确、及时的发现业务是否有异常。为了达到这个目标，我们引入了称之为智能基线的系统，这个系统可以在网上搜索到。这个系统效果还是不错的，能够在没有任何阈值或者规则输入的情况下，自觉做预测。同时有些业务发展比较迅速，我们可以比较好地在历史的长期趋势和短期的业务沟通之间，做出一个相对较优的折中。业务变化之后，假设你以前配了阈值还要改，智能基线不需要改。阿里巴巴几千项业务指标，通过人工的检查验收之后的准确率是在80%以上，这个数字每周都不一样。而对比传统的工程师通过传统的静态分段阈值或者环比的方式，准确率可能只有 40% 左右。大家可能也会看到特别对于业务量监控，可能 10 条报警里面，4 条真的觉得有问题已经不容易了。阿里有很多不同的业态，所以一套系统解决所有问题还是挺难的，因为不同业态之间的差异还是非常大，数量级、波动、周期均有差异，包括现在有新零售业务，它是把线上线下的业务结合起来，而且非常强调线下。比如盒马鲜生有几百家门店，这是个商业的尝试，对于做运维监控的同学也带来很多挑战。比如淘宝和天猫的某些交易量在分钟级别是万或十万或更高的数量级，这个可能就是百或几百，波动的量级和原始量级在一个量级上，这个就比较难处理。包括周期性，对于一般的在线服务，是7X24小时提供服务，每天什么时间流量最低？国内业务凌晨四点钟最低，这个会受门店的开关门影响，因为零售是有时间的。我们如果线上刷淘宝下单点一下就行，线下不一样，一对一排队结账。而且在量小的情况下，很多时候不能看单一指标，许多指标要一起看，所以就给我们之前的算法提出非常大的挑战，我们需要做新的算法演进。大家可能会问为什么整这么复杂的算法。配监控，配规则不就可以了吗？其实是可以的，但业务太复杂。作为一个横向团队，算法工程师可能只有三四人，七八个人要面对阿里巴巴集团成千上万的业务监控指标，不可能了解每个指标的所有细节，这个时候是没有办法用人，我们要用机器学习的方法去做。二、增强版的时间序列异常检测实战接下来讲讲怎么用机器算法解决问题，这是一年半以前我们采取的架构，我们能从业界很多文章上看到类似的架构。我们希望做一个基线拟合，这个曲线应该是什么样，我们说异常这两个字就是异于平常。我们第一步想知道正常的曲线是什么样子，所以我们做基线拟合，我们用STL做这样的方法，我们用比较传统的 N-sigma 做调整。这种架构其实能解决 60% 左右的问题，但是有些极端的情况解决不了，所以我们就把架构做了演进。我们第二代的架构做数据预处理，然后又做了比较简单的滑动平均，数据有时候会缺点，不管是采集侧的一些不稳定因素，还是计算一侧出现了问题，导致你希望一分钟出一个数据点，但是最后还没有算出来。这种情况应该从工程上解决，所以我们会在算法层面做一些脑部的算法策略，就是即使缺了能补回来，但是不能长时间缺数据。下面的逻辑就走了机器学习的思路，我们对曲线做特征工程。我们之前的基线拟合的这种预测只是我们特征工程中一部分，对于重要的部分，我们也会把一些统计特征编码进去，当然也会把一些时间特征编码进去。因为我们知道很多电商的业务是有定期促销的习惯，比如淘宝的交易量每天早晨十点一定会有阶峰，大家不知道在抢什么东西。算法层面怎么解决？我们把每天的这个时刻第几小时第几分钟，通过热度编码的方式做到里面去，就可以让算法学到这个时间点这样一下可能是正常的。我们后面采取了不同类型的统计学的判断和做法，最后做成集成策略，大家可以理解为简单的投票策略。它其实给我们带来了比较好的一些算法的效果，比如说基线拟合会更准，对于不同类型的异常进行判定。很多时候曲线有不一样的异常，如果用 N-sigma 的方式，你的刻画表现能力是不够的。即使是这样，对于遇到的新零售业态，我们觉得还是不够。因为你看刚才的算法能解决一般性的问题，但是对于曲线问题差异很大的时候，之前的预处理就需要增强，量级从十万左右到几百万，你的预处理策略需要变化。很多曲线不具备周期性，或者周期性非常零乱。比如我们有一个业务比较奇怪，大家在淘宝上有没有充话费？这个是天、周、月三重周期，天的话基本没有问题，周的话工作日和周末是有差异的，月这个周期，因为大部分人是在月末报警了或者月初充。最后一个线下的业务对这种异常很敏感，在这种情况下我们用一套算法策略是解决不了不同问题的，所以我们做了第三次优化。我们先引入了一层算法路由，希望能够通过机器学习的方式，把不同的曲线归到不同的算法路由里面去，这样的话不同的曲线走不同的处理路径，那么效果会很好。我举三个例子，比较周期性、非周期性、百分比的指标等等，这些不同类型的指标方法都不一样。在这些不同的方法之后，我们还是觉得算法也许解决不了所有的问题，因为算法对于大多数运维工程师来讲，不见得那么方便去调参数，所以我们也开放了三个参数，我们会看它不同的抑制时间、发布策略和敏感度。分开来看，算法路由，这个工作的目的就是说让算法自动把数据分类，这一块也不一定非得用算法，用人就可以，但是因为量太大，所以人工的成本很高。这里我们用了深度学习的算法，上面那个图是网络的图，我们使用了孪生网络，两边都是LSTM，所以我们用了双向的网络结构去把我们标记为一样和不一样的，最终能够区分开。在这个基础上，我们做了一个分类模型。这块从技术层面来讲，不用特别复杂的算法，我们用这个算法就是想探索一下，实际大家真正做的好的话，比如你用一般的分类方法，用我们最直接方法也可以达到类似的效果，但是我们这里尝试了一下。分好之后有个工程架构，以前是说不同的算法场景走的处理逻辑都是一样的，里面的参数可以不一样，后面不同的处理逻辑像插件一样可以去做组合，这个组合的变化频度不会太快，但是一般变化成本都很低。这样以前是三条通路，我把插件的参数和顺序和有没有插件做一个变化。有了这个之后，对于阿里巴巴成千上万条，但都是到万这个级别，不会再多。大家会想这个东西可能是从业务角度监控的，从惯性思维来看，我们可能会是想监控 CPU 或者某个接口调用的超时，这些也是可以的。我们也探索了在系统级指标或者非应用级指标做这个尝试。它的周期性不太明显，第二个这个指标的变化跟业务行为关系不那么大，运维的决策对它的曲线影响大于业务的影响。最后一个就是标准不统一，你觉得这个可能需要报警，别人可能觉得不需要报警。我们采取了一种轻量级的方式去做检测，可以做到自动学习。它跟上面那套算法相比在于它比较轻，可以做成一个包的形式，嵌到监控系统中去做监测。它的效果如上图右边显示，我们内存中有奇形怪状的异常，这个算法逻辑还是比较简单的，不用太在意算法本身的框架，因为这些算法你可以替换成其他的算法，但可能需要考虑在数据进来之前做比较好的预处理。第二个可能你需要基于统计特征和那些曲线本身的特征，影响你的特征工程。最后孤立森林不是说基于用户的标注去做的，因为实际场景中我们不可能像做人脸识别这样给我们标注。什么参数微调？第一个是说抑制报警的时间，这个很容易理解。第二个防抖动策略，这个也很容易理解，就跟过去 N 分钟有 N 条报警是一样的，所以我们概括成N/M。最后一个是报警灵敏度。这个在我们市场环境中测试的效果大于70%，现在这个数字可能稍微好一些。最终怎么评价算法？还是要看人标的。比如说我们有十几位同学评判，他们的标准也不统一。甚至一个人今天说这个点标的对，第二天忘了再看一遍就说标的不对。所以说以上是我们介绍的关于单个指标，不管是系统级的还是业务级的指标，怎么通过机器学习的方法，做不用任何监控阈值配置和维护成本的智能监控。三、多指标关联分析的探索刚才也提到了在新业态下，很多时候我们只看一个指标是没有办法判定业务有没有异常，或者我们发现指标和指标之间是有关联的，这个在实践当中也会遇到。有时候两个指标都出了问题，这时这个信息能不能被利用，我们也做了探索。这个东西有一个业务背景，就是我们刚才提到的看一个指标不够，我们经常在一些业态里看到会监控某一个业务的成功量、成功率、失败的错误请求数几个指标相关变化。有时候会发现指标有异常传播，这个传播有几种方向传播。比如说在不同的业务之间传播，比如因为两个程序之间有关联关系，A坏了B也影响了。还有就是混合部署的情况，同一个集群布两个业务，A被打爆，B也被压死了，也有这样的情况。我们怎么做这个事情？分为两步。第一步我们希望发现和维护相关的指标，就是哪些指标应该有关联的，发现之后要维护。一旦我们掌握这个信息之后就可以做两个事情。第一种我们能够把这些相关指标放在一起判定业务是不是异常，而不是只看一个指标。第二种我们单指标能看的很准，但这时候我想知道为什么会下跌，虽然给不出因果，但是可以给出相关。业务指标之间的相关性其实有不同的类型，比如上下游之间有监控项，比如我们在阿里做过一个实际情况，大家看淘宝搜商品，如果出现异常大家就搜不了东西，我们的淘宝详情页的浏览量和下单量都会下降。不是说搜索的程序或者应用服务掉了那个服务，它们之间没有关联，但是很多用户习惯了搜而买。一但搜挂了，很多用户不知道怎么买了。所以这样的关联靠系统内部是拿不到的。包括业务不同分量的监控，比如河南省播放成功率和河北省播放成功率之间的关联。这种关联我们怎么发现？一定是靠人工梳理，但是对于阿里的体量，一个是梳理不过来，第二个梳理以后过两天又变了。阿里集团可能每天的业务发布的频次是千级别的，那怎么办？还有第三种方式。第一种利用 CMDB，我们通过CMDB看到哪些应用之间可能相关。第二个通过 时间序列相关性 发现了方法，这个跟刚才提到的卵生网络的方法是类似的。但从实际来看，一般是在第一个检测的基础上，再在局部做第二个，而不是全局的检测。第三个我们利用关联规则挖掘看哪些项经常关联报警。我们可以通过算法发现这些关系，这三个方案其实是互补的方案。所以有了这三个方案后，就可以把很多相关的指标放在一起监控，方案取得了较好的效果。在盒马鲜生，基于我们上面做的新的算法，单指标架构和多指标关联架构，能够把监控发现率和误报量做非常好的提升，这就是我们在新业态下通过单个指标的算法和多个指标的算法取得关联效果。四、故障影响面和根因分析的探索之前都是关于监控的部分，监控是为了发现问题，但是发现完了问题，很多时候是需要想怎么能够解决问题的。我们在故障根因的推荐层面做过一些探索，但这个也只能是探索，供大家参考借鉴。首先我们看一下故障原因分析问题的范围和边界，我也跟很多工程师交流过，凡是做运维系统的工程师都有一个梦想，就是我想做一套系统，一旦我的业务出问题，告诉我问题原因在哪，这个非常理想化。但在实际过程中，这个事情是非常难解决的，探索来说在阿里内部也解决地不好。虽然解决的不好，我们也做了一些探索。为了避免我们做的事情不符合我们老板或者客户的预期，我们需要先把能做什么说清楚。我们很难做到淘宝交易量下跌了，我告诉你哪个代码有bug，这个做不到，但是我们能做到缩小影响范围。这个为什么有价值？因为阿里巴巴有两到三万名工程师，半夜两点出了问题，我打电话叫起来就是一个非常复杂的技术问题。首先要从阿里巴巴几万个应用程序里，先要看这个业务故障到底跟哪几个应用相关，这个都是非常典型的问题。我们的目标是能够从站点、产品线和业务功能指标出现问题的时候，能够定位到应用服务层，包括数据库这层。这个架构就是能够锁定这个范围，然后之后的事情可能需要更细致的方式解决。另外一个好处，我们可以对故障做一个结构化的快照，除了阿里巴巴，我看到很多公司也会对故障做复盘做改进措施，但是没有形成很好的流程。但是在阿里我看到过去大大小小非常严谨的复盘和故障记录，包括非常多的细分的环节和字段，这个非常好，因为以后的故障可以从中学些东西。但是有个遗憾，这些东西全是用汉语写成的，长篇大论几千字。人可以去读，但是比如阿里有另外一个工作叫全链度压测，我们要对去年的业务优先进行测试，这个时候我们要挖掘到底哪些有问题。挖不出来，为什么？都是汉字写的。汉字写的话，它的表述、格式，都是很难被机器理解的。如果做的这件事情以后出故障，我们尽可能地把故障做一个结构，这个不仅对这次故障的本身，对以后故障的防范都有非常大的价值。怎么做？如上图所示，我们会有一个主的抽象流程，当我们的前面算法发现问题之后，我们会尝试找到跟这个业务指标相关的应用和它的中间件以及数据库，以及相关的网络服务器IDC。我们建立了一个囊括阿里主流的所有运维相关事件的这样一个数据仓库，阿里内部可能有自己的这种事件存储的机制。这个数据仓库能够告诉我们在哪些运维的对象上发生了什么事情，最后我们对这个事情做一个排序和筛选，把可疑的挑出来。逻辑还是比较清晰的，但是真正做的时候发现有很多具体的环节需要考虑。比如你怎么找到监控项关联应用，淘宝交易下跌了，你怎么知道是阿里的几万个应用中哪个应用造成的问题？这个其实也是比较难的问题，我们也没有解决太好，但是可以看到思路。最直接来讲，我们通过监控系统本身的配置来得到。我们的业务指标能画成一张趋势图，能做监控，因为背后有逻辑计算，有日志的采集等等。这些系统的工作，是因为加监控的同学已经把监控怎么采集配置进去了。但是它有失效的时候，比如说两种情况。一种发现业务环境非常强，ABC三个程序不断做处理，最后把结果打到第四个程序上去了。所以你通过这个，能得到第四个应用的名字，前三个应用其实跟这个业务非常相关，但是你从这里读不到，所以这是我们要解决的。第二个有一些应用本身是用来监控的，比如阿里的客户端，它会上报到某一些监控系统，这时候监控系统画出来的曲线，其实跟监控系统本身相关的，而不是跟产生监控数据的应用相关的。这种情况下，这个方案就失效了。这个时候就需要通过人工配置的方式解决，目前是这两种方式结合在用。刚才说的第一个问题，我们也可以通过阿里巴巴的中间做的系统去解决这个问题，包括我们也可以通过算法，对于报警做平台挖掘，可以挖掘出来像刚才搜索框下跌，导致交易量下跌的关系等等都可以挖掘出来，这个东西也是补充的方式。但是最核心的不是算法，最核心的是CMDB如果维护得好，比什么都好。通过刚才那个思路，能够把我们的业务指标跟应用结合起来，但是很多时候应用经常是无状态的，状态存储在数据库集群里面，这个时候还是经常通过CMDB解决这个问题。还有比较难的问题，就是网络跟应用程序的关系，有一个机房出问题了，经常我们是混合部署的，所以这个时候问题其实是一个非常散的关联，这个问题上我们解决的也不好，所以我们只能把这个信息当成一个缺少的信息推荐出来，供大家去决策。比如说不管阿里什么业务出了问题，我们都会把网络最近出的一些异常点或者事情推送出来，提醒大家是不是这个问题，但是这块很难做到精细的管理。我们知道了哪些运维实体跟业务有关联之后，还要知道这些运维实体上、程序上、集群上、网络上发生了什么事情？那这个事情我们怎么知道？我们会建立一个在线的数据仓库，它能够不断地抓取来自于各个运维平台和系统中的不同格式的事件。这个抓取之后不是简单放一块存，还要建立关联索引。阿里有很多不同的横向纵向的系统，他们的数据格式的字段都不一样。我们尝试做一个翻译，在当中找到了两三个大家都能看懂的词。比如钉钉应用，这在阿里内部非常稳定的。第二个IP地址，这个也是很稳定的。但是这两个之外，格式语言是不一样的。我们把数据仓库建好之后，输入开始时间、结束时间和应用列表三个关键词，就可以查到这段时间内实体发生了什么事情。我把事情都推荐出来是不是就解决了？还不够。我给大家分享一个数字，在阿里巴巴内部，像这样的事情一分钟发生四千到六千次，也就是说一个故障如果持续了十分钟，就是几万个事件，所以我们还要再做筛选。这个时候就会通过一些方式做筛选，我们会根据哪些运维实际上发生了报警，把这些实体的信息优先放在前面。怎么知道有跳变？我们会对怀疑的对象做系统级指标的扫描，扫描出来跳变就排到前面去，所以有了这个之后就可以相对精确地缩小范围，当阿里巴巴淘宝天猫有异常的时候，我就可以知道。我们能够从上面看到，最上面这个环节是同一个时间内有多少业务的多少点在报警，红颜色的时候，可能就是某些业务出现短暂的异常了。我们会感觉 CMDB 加平台化算法对报警压缩合并，看到了集中在优酷、集团客户体验、菜鸟这三个业务功能上。这个其实就是刚才讲的多指标关联分析的作用，这时候我也不知道是不是因为它导致的，但是他们之间是相关的，这个可以帮助我们定位。最后我们能够根据刚才说的逻辑，把跟这个事情相关的前五个或者前十个应用程序推荐给你。为什么推荐给你？要么它发生了一些骤变，要么发生了一些大的业务操作。很多时候可能百分之五六十的业务故障，都是发布新功能或者改配置改错导致的。做的比较好的地方，可能能够做到70%以上的推荐准确率。但是也有做的不好的，百分之三四十的准确率。因为阿里业务很复杂，每个环节每个业务都有不一样的方式。但是这个方法，我认为还是一个值得推广和借鉴的大逻辑上的思路，这个就是我们介绍的监控发现问题之后，我们在根因分析层面有哪些探索和思考。五、智能运维在故障治理领域的未来规划最后希望能够和大家一起探讨一下在智能运维领域现在与未来可以做什么事情。运维本质上是解决在线服务运行中的质量、成本和效率三方面，运维不是从上到下的思路，包括我也参与了白皮书的工作，我们也跟其他业界的同事探讨这个问题，不是说有一个顶层规划要怎么做，实际是在这些点所处的具体环节上，很多工程师开始尝试用算法的方式解决问题，逐步汇集成一个数。我们现在在上图左边那条路做了一些探索，已经在业务中用起来了。最早的探索，其实在阿里内部已经稳定运行了接近两年时间，也是效果在不断演化演进。最近我们也在探索右边这条路，就是无人值守相关的东西。出问题的时候很多人问淘宝的故障恢复了没有，支付宝有没有受影响。靠自然语言提出的问题，是不是可以通过机器人回答你，这个也是我们探索的。当然现在还不敢做全自动，还是我们列出来你再确认一下，但已经比你调出系统然后跟很多人沟通半天决策要方便一些。所以其实不仅是在质量领域我们做智能化的监控，智能化的根因分析，其实在节省人效率层面，也可以做一些探索。中间这块跟成本相关，这块在阿里巴巴有很多团队做这样的事情，也可以通过智能化的调度能够做容量预测，优化包括硬件采购的周期，预测你服务器增长怎么样。或者在实施的时候，通过自动化的调度策略，节省服务器的资源。所以其实智能运维这个概念，在今天已经不是个概念，它已经在我们企业实际工作中，有非常多落地的点。希望今天我的分享，能给大家有一些借鉴和参考，我们一起建设智能运维美好的明天。说明：以上内容为阿里高级技术专家王肇刚在 GOPS 2018 · 上海站的分享。本文作者： 王肇刚阅读原文本文来自云栖社区合作伙伴“高效运维”，如需转载请联系原作者。