在互联网业务运营过程中，通常主体业务流程都是由程序自动执行完成的。但一些运营辅助的工作，尤其是执行频度低、需要跨平台操作、规则复杂的业务运营任务（如：天猫商品的上下架，营销活动） 实际上占据了运营同学大量的时间。当这类需求用程序来实现自动化操作而又缺乏通盘规划时，就会演变成平台的一场噩梦。
复杂的规则很可能与平台已有的主体业务逻辑存在局部冲突。代码中不得不增加个性化的判断，才能针对特定的场景执行特定逻辑。个性化的逻辑无疑增加了代码的复杂度，再经过几个月，如果当时开发同学离职了（这在互联网公司也是常事），可能已经没人知道有这样一段“个性化”代码存在。就此平台上多了一个飘忽不定，不知何时有可能被触发的业务“幽灵”。
跨平台操作（这里指合作方的平台，通常是为人工操作设计的），可能仅仅是自动登录就搞死开发同学了，更不用说里面经常变化的操作过程。搞不好，费洪荒之力开发的自动登录还会因为登录方式调整而不再可用。
低频任务，降低了问题被及时发现的可能性。等到运营同学想再用的时候才发现怎么都用不起来。只好找运维、开发查日志，查源代码一通折腾。这时，为了应急通常是用人工替代自动化操作。原本自动化的操作很可能因为修复成本过高而就此回退到人工操作的蛮荒时代。
这类运营任务因其频度低、变化快的特征使得自动化成为了一柄双刃剑。在提高运营的效率的同时增加了平台逻辑的复杂度，把控不好就是一场灾难。
自动化是降低人力成本，提高运营效率的必然路径。如何能够即实现运营的自动化又不对主业务逻辑造成太大影响，同时还能满足业务逻辑变化频繁的业务目标？
为了实现这个目标，我们尝试了借鉴自动化运维的思路：基于应用平台开放的数据或能力（API），用脚本的方式实现业务逻辑。
先不说平台的能力开放，这对架构设计的要求很高。一般业务平台，尤其是新业务的平台，在还没有验证业务市场空间的情况下是不会更多考虑能力开放的。毕竟生存是第一要务。因此先从数据开放入手，这个实现简单，只要有数据库的只读权限就可以。而且，关键的业务用户、业务数据、配置数据都可以获得。
实现自动化的任务也要有所筛选，能够在不直接写平台数据的情况下也能够完成的任务是自动化的首选。根据任务目标特点选用脚本化的编程语言来实现业务逻辑。我们的目标是要自动化完成跨平台操作，Python成为不二之选。
Python容易理解，运营同学经过学习后就可以对业务逻辑做一些微调整，这有利于快速优化自动化逻辑。
经过一段时间的尝试，总结下用脚本代码实现自动化运营的优点：
1. 不用写交互UI，省去了不少时间，相当于开发提速了；
2. 不用纠结于哪些参数做到配置界面上，全部在源代码上搞定。不怕参数多，用段时间就知道哪些是需要在业务中经常调整的关键参数了，为产品化提供了依据；
3. 业务逻辑在代码层面可见，运营同学一般能看懂个七七八八，和开发同学就实现逻辑的沟通效率提高了；
4. 开发中把屏显日志做到清晰明了，运营同学看到翻滚的日志，有什么问题一目了然；
5. 任务的执行频度低，可以放在笔记本上执行。顺带规避了一些网站对IP地址访问的限制，WiFi连上手机网络，毫无后顾之忧；
6. 技术实现困难的环节（比如：登录），加入手工参与，避免了“英雄难过美人关”导致的延期。
脚本自动化运营中的问题也是有的
1. 代码的版本管理不善可能会导致用错了脚本，会产生什么后果相信大家也能想到了。
2. 对运营同学的要求提高了，能读懂部分代码，又要能了解些数据结构。这运营同学的身价得见涨啊。
这种自动化实现方式非常灵活，执行脚本独立，不影响主体业务逻辑。
目前的尝试还仅仅是在数据开放的基础上，适合不完善的新平台以及一些架构臃肿无法动弹的老平台。
试想，如果平台具备API开放能力，自动化运营完全可以通过调用能力API，来实现复杂的业务逻辑。自动化运营的施展空间将更加广阔。
