重要数据的变动记录，及保留历史版本
对重要数据变动，做日志记录，必要的保留历史版本。可选技术方案：将所有历史版本数据存储在k-v表中，允许随时丢失部分或全部
缓存、临时文件及日志
允许这类数据存储在易失性设备上，如内存缓存。允许随时丢失部分或全部，程序不得崩溃（鲁棒性）
自己擦屁股，自动归档旧数据，尤其是存储到数据库中的旧数据，如日志表，临时文件等。至少要有相关文档，指明哪些是此类数据，如何清理，清理是否会带来后遗症（理想 状态是可以任意删除，程序本身健壮工作）
用户行为记录
uv, pv, 类似GA ，或者直接使用第三方服务
单个用户的足迹，按用户、回话划分。登陆用户的记录很自然；非登陆用户，也要有区分方案，可以类似于app中device token的实现原理。负载均衡下要按session划分。
关键步骤的记录。
分别对待:
不产生服务器上数据变更的行为，注意是浏览、搜索等行为，类似HTTP get方法的约定。选特定行为，做记录
产生服务器上数据变更的行为。无条件记录：数据产生人，时间，源IP等必要信息。数据更改及删除，还需要记录原始数据，目标：可快捷低成本的追溯历史。
统计类数据
统计类数据，如文章点击量，定期快照（如按月、天、小时），或者记录一定粒度（如小时，天）时间段的统计量
防范资源滥用
高资源消化的操作做qps限制
关键请求上，针对单用户限制授权额度。这里的“用户”是宽泛概念，可以是用户账号,session, ip等多种
信息分级(信息安全层面)
防止重要信息被批量采集，将这些信息分级，对不同用户级别用户展示相应部分。初级用户只能看到极少部分。
严格限制列表页：不得查询未授权的内容，防止越权读取。
信息分级(业务层面)
不同级别的信息，有差异的对待，保证信息准确性，可追溯性等。
从生命周期对信息分类，尤其是对主体信息。这里的“主体信息”，是一个模糊概念，暂时简单的理解为：在数据库里以单独表形式存储的信息，每条信息对应一条记录。划分方式相对个人化、主观化：
- 长期有效信息：知识，规范手册，等
- 中长有效期：，
- 短有效期：，
- 即时有效期：
按信息对业务重要程度划分，
- 重要信息
- 次重要信息
- 不重要信息
- …
账号密码管理
传统的用户名密码方式，在实际使用过程中，使用人员一定会共享账号，且密码修改非常不及时。（通常是将账号密码放在文件里，如果有工作交接，直接将文件转发，或者直接在QQ里发送账号密码。因为这比“找相关人员新开设账号、设置权限”简单太多了为了。为了不影响别人使用，所以几乎都不会改密码）然而这都是重大的安全隐患。
邮箱作账号，登录后通过邮箱做验证，避免账号共享，强迫通过管理人员赋权限。企业邮箱是第三方服务，一般有较好的密码策略。
用户在同ip段登录只验证一次，若干时间内不需要重复验证。
如果多个用户在某ip段成功验证，其他人员也可以在该ip上通免验证。
超过一定时间不登录的账号，禁止登录，需要重新邮箱激活才可。
超过一定时间不使用的权限，自动撤销。这样，通常就不需要管理员取消授权。
用户管理
对用户按权限分级，如果需要的话（普通用户登录，超级用户）。权限可以查阅、发布来划分；对于管理员，则按增删改查划分。
用户状态，在登录时有相应提示，减少用户登录时提示信息异常造成的困惑，即使对已封禁用户（制定一系列状态，如：临时拒绝登录，禁言，封禁，异常锁定等）
保护用户隐私
关于请求数据
post/get之辨
请求参数格式，url简洁，事先评估是否实现rewrite兼容性
针对移动设备的http接口请求，要实现类似user-agent信息，在请求中传递，可以在http协议头中传递
功能设计原则（底线）
不希望用户操作、不希望用户看到的东西，不要列出来
必要的说明：正确，简明，有效，隐藏
不挑战用户习惯
一致性（提示文案的一致性，同类功能操作方式一致性，UI元素摆放位置一致性，etc)
功能设计原则（价值点）
有转化，可转化
有用的参考资料
- 信息安全标准目录 http://www.cnblogs.com/merray/p/5315066.html