天涯社区是一个典型的中型互联网公司，目前的现状为：
1、千台服务器规模，近10G的流量，日PV亿级，每秒用户会话几千;
2、2个数据中心，1个主机房，1个分时数据备份;还没有实现双机房冗余，即应用和数据的实时同步;
3、运维团队规模不大，人员流动性大，要求运维工程师多面手;
4、业务繁杂，产品运维支持困难，产品变动大，服务器经常在不同的产品间相互变更。
2002年我进入天涯，02年的天涯仅十多台服务器，1名sa。当时运维团队的重点是创收，所以运维团队的工作中，运维仅是一小部分。运维部门的重点工作是做项目搞创收。几年以来实施的项目有系统集成、网站开发和托管、机房建设等工程。
比如海南省某银行的机房工程项目，从方案设计到机房施工，包括布线、装修、消防、空调、新风、强电、防雷等几百平方米机房建设项目，全部由我们这支廖廖数人的队伍完成。我们实施的网站开发与托管累计有数百个，运维团队和技术团队共同在天涯运营最困难的时候，保住了天涯顺利渡过互联网寒冬时期。
几年后，随着互联网复苏，天涯流量不断翻番，运维部门逐渐从系统集成项目抽身而退，工作重心转移到天涯网站的架构扩展及运维之上。在天涯网站调整发展时，国内的互联网无论在网站架构或是运维上资料极少，不象现在这么丰富。所以我们只能是边摸索边测试边实践。
最早期的天涯是ASP+MSSQL Server的二层结构，应用层通过ODBC直接访问后台数据库。产品功能设计非常简单，缺乏基础产品，例如没有搜索产品，标题搜索直接用like来匹配标题字段。这样的程序实现在访问量一大时马上把数据库堵死。这个时期的运维团队仅有2个人（最早的sa因待遇太低，跳槽去了省级报社），面对访问量一大就崩溃的天涯网站，我们开始和技术团队一起开始了天涯运维的第一阶段，架构扩展阶段。
天涯是个动态内容网站，所有的内容直接从数据库生成，也就是说，用户每访问一个帖子，都会在应用服务器逻辑计算一次，在数据库后端生成一次事务，一天上百万的PV就是上百万的数据库事务，对应用和数据库压力非常之大。我们当时参考了车东等网上技术大牛的博客，用squid在前端做了被动内容缓存，应用层用ASP函数生成HTTP过期标记。帖子页面过期时间为5分钟。
squid初上线时的命中率为45%左右，不算高，于是我们又在squid的前端加了一层反向代理haproxy，使用haproxy通过url hash将指定的url由统一一组squid来支持。通过这样的策略，命中率提升到70%多。数据库扩展方面，我们用最简单的办法，分库。原来的版块是一张表，分库后每一个版块是一个独立的库，访问量大的版块甚至由一组独立的数据库服务器承载。早期的数据库平台是MSSQL Server，我们用日志复制的方式来做双机，发布和分发服务器是主，订阅服务器是从。
后期迁移到Mysql后就更简单了，一组服务器由一台/二台master和多台slave组成。master负责写，slave负责读。目前架构设计正在考虑通过NOSQL的架构重新将所有版块库组成一个更大的，支持更高水平扩展的分布式虚拟数据库。面对早期的windows服务器，运维团队很难对其进行自动化运维，所以当时sa最烦的事情就是软件部署、补丁升级、服务器重启及配置管理等重复劳动的工作。当时的运维基本上靠手工和一些简单的运维工具。
