InfoQ：关于库存方面，在线上和线下的库存分配平时是如何安排的，在大促时如何调整？是否存在动态调配方案来解决库存分配不均的情况？
孙迁：苏宁各销售渠道的库存是共享的，尤其随着O2O的进一步探索和演进，对要求共享库存的场景越来越多，如果连库存都不能共享的话，则很难做到各渠道的融合。
具体的技术实现分两种类型，一种是数据上完全共享，另一种是动态调拨，这两种方式在苏宁当前都存在。
拿动态调拨来说，基本实现原理是为不同渠道设置不同的预警阈值，超过阈值则触发自动调拨操作。如何能更高效地进行调拨及如何能尽量减少调拨导致的渠道无货或者货物卖不出去的情况，这些需要结合着商品特性、销量预测以及仓库分布及辐射能力等情况去综合分析，而不是单一地靠静态库存数量来进行调拨，这样的话势必会出现各种问题。经过了多年的优化和积累，目前苏宁在库存这方面基本不会存在库存分配不均或者单渠道无货的情况发生。
InfoQ：能否为大家总结苏宁云商大促时容易出现哪些系统瓶颈，能否进一步地谈谈针对意想不到的大流量时，你们大促当日会有哪些应急手段？
孙迁：在高流量场景下，任何一个细微的问题或者瓶颈都有可能会引发巨大的故障。故我们从包括但不限于物理层面的链路流量、负载设备及机器计算能力等，到中间件层面的各种参数设置、应用层面的性能状况以及业务系统层面等都会存在各种瓶颈和异常。
应对不同层面、不同场景的瓶颈处理方式既相同也不同，whatever，一套完整的监控体系是所有业务及系统稳定运行的根基，避免完全不清楚系统运行状况的场景发生。目前我们在物理层、中间件层、应用层及业务层等各个层面都进行了大量的运行时数据采集，以及具备实时数据分析的功能，任何一点异常情况都会被立即发现并触发不同的处理预案，定期会对系统的运维状况进行巡检及总结，同时在新系统上线前会进行多轮的功能、性能以及线上实际引流及放大回放测试等工作，绝大部分的问题都会在系统上线前被发现并解决。
严格来讲所有的系统设计在一定程度上都会有一个上限，或者面临各种“意想不到”的场景。比如网络蜂拥或者其它超出了系统设计容量的场景，这个时候常见的处理方式会采用业务降级，极端情况下会采用流控等策略去处理。简单来讲就是牺牲一部分业务或者用户体验来减少对系统性能的消耗，从而保证核心链路的稳定。
随着能力的提升，各种“意想不到”的场景往往会变成“假设存在”的场景被考虑，比如流量蜂拥，机器宕机，业务异常等。目前我们总结了几千条异常场景，同时都会有对应的应急预案。一切的一切都是以快速恢复服务，减少对用户的影响为最终目标，而不是当问题发生时再去思考如何解决问题，这样会显著加长问题的处理时间，会对业务及用户带来很大的伤害。
InfoQ：大促高并发下如何快速定位到错误发生点并解决？针对系统问题，能否介绍运维人员大促常用的预备方案？特别地，哪些预备方案是你们最关注并反复演练的？
孙迁：快速定位错误发生点的前提是要有完善的监控体系，这样在事前或者事中可以快速发现异常，同时必须要持续积累和完善各种应急预案，知道异常发生时如何快速应对，这样两方面结合才能更快速解决问题。
我们其实没有常用和非常用的应急预案例，往往概率越高的问题越会被重视，随后慢慢演变成一个常态，也就无应急和非应急之分了。
给系统带来最大的不稳定因素还是来自于各种偏门的场景，尤其是没有预料到的场景。一切影响核心链路稳定的场景基本上我们都有反复演练，比如关键及非关键业务系统宕机等场景。
InfoQ：您在ArchSummit演讲中将会提到“架构设计意识的转变”，优秀的架构师应该具备怎样的架构意识？能否结合自己十多年研发经验提前为大家分享这个体会？
孙迁：经历了这么多年的业务及系统设计经历，让我体会最深刻的一点是在不同时期及能力下对于问题处理的思路和逻辑的不同。