序言
东南亚人口红利刚刚在慢慢爬升，随着经济的迅速发展，对于移动互联网有着天然的亲和度和接受度，较多的产品可以在东南亚市场中进行试水，并能取得一定的成功。
但这片市场受到越来越多的全球性企业的关注，会由无竞争市场变成充分竞争市场，一旦出现市场竞争，一个富有战斗力的团队的价值会更加凸显。
技术方向
对于需要快速上线产品的市场，快比一切都重要，但是需要合理的快，并且快的有价值，不出错，实际上对于很多的创业公司带来较大的挑战。产品的快速迭代上线，如果品控把握不好，当竞品出现时，很可能因为品控的问题导致产品失败。
特别当有了成熟框架、组件及运维体系的情况下，能够加速开发，缩短产品上线周期，并且对于运维、品控来说会有较大的好处，也容易形成产品需求提出、开发、测试、发布、用户反馈这样的闭环体验。
打造一个合适的技术架构、组件不是一朝一夕能够完成的，投入少量资源选择一个合适的切入点尤为重要。
一个完整典型的构架体系，分为多个层级
- 操作系统及运行环境
- 操作系统 —— 统一的操作系统内核，保证团队间的环境一致，并且资源池（提前准备好的机器，可随时扩容给需要的服务）的机器状态也一致
- 运行环境 —— 保证系统库状态一致，避免运行库版本不一致导致的异常问题
- 程序框架
- 通常为了简化程序开发，将程序的网络通信接口或者服务单独剥离出来，开发者只需要编写服务相关的代码。如python的django、flask，java的spring框架等
- 程序应用层
- 即当使用程序框架时，开发者需要编写的应用相关代码
- 监控
- 机器数据监控
- 网卡流量、包量
- 内存使用率
- cpu使用率
- IO使用率
- 机器负载
- 应用数据监控
- 由开发者自己指定的数据上报项
- 机器数据监控
- 告警
- 针对应用程序指标，发现异常时进行的告警。需要尽量简化程序开发工作，复杂的开发会导致大量需要增加搞定的地方无法增加，或者因为麻烦而不愿意增加。但会影响到系统的稳定性以及是否能及时发现异常。
- 统计
- 将监控数据项进行汇总，或通过日志输出的方式，计算出业务的相关指标，提供给产品及老板作为参考。如活跃度计算、地域聚集性计算，版本更新计算等其他数据
- log上报
- 下发指令给客户端，要求将客户端的日志上报到服务器。前后端同事可以迅速的定位问题
- crash上报
- iOS及Android产生的crash信息，可以有效的将crash堆栈信息上报至服务器，由服务器汇总各个版本的crash情况，并给出分析指标和路径
- 日志输出
- 服务端将相关的数据通过日志方式进行输出，由数据统计人员进行分析并入库
现状
相对而已，上面所讲述的各个点都有一些开源软件可以使用
nagios作为基本的机器属性监控
influxdb作为log数据存储
grafana作为数据展示平台
但这几个工具的易用性明显不足，可用，但不好用，导致在开发时期无法关注到核心的数据和指标
短期可实现内容
基本的组件——agent+api，可用于监控统计、负载均衡、配置管理
已有模型（模型图）
- 优点
- 简单、高效
- 易于开发维护
- 对程序员友好
- 可扩展性好
- 缺点
- 基础代码关键
- 前期需要前端页面投入
- 周期
- agent基本组件——3人周
- api——1人周
- 数据入库——1人周
- 数据展示——不定
- 数据告警配置整理输出——1人周