使用glusterfs来实现文件服务器高可用

由于项目需要,需要对文件服务器实现高可用。之前想过一部份方案是nfs+rsync+inotify+keepalived 这样的方式。但是有很多问题,很多服务器mount之后一旦主的nfs挂掉之后,需要在client服务器上重新进行mount这样的操作。

于是考虑到使用分布式文件系统,这个网上有很多文章来进行比较的。我用这个主要是它的部署方式灵活,没有单点问题,可以mount(通过fuse)

下面就是具体的部署过程,我的操作系统是centos5.6 x86_64

client的IP为:192.168.0.201
server的IP为: 192.168.0.202,192.168.0.203

server端共享的文件夹为 /home/filecluster
client端的文件夹为 /home/filecluster

修改3个机器的hosts文件

192.168.0.201	xen1
192.168.0.202	xen2
192.168.0.203	xen3

首先是需要下载fuse和glusterfs,以及python-ctypes

wget http://download.gluster.com/pub/gluster/glusterfs/3.2/LATEST/glusterfs-3.2.2.tar.gz
wget http://downloads.sourceforge.net/project/fuse/fuse-2.X/2.8.5/fuse-2.8.5.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Ffuse%2Ffiles%2Ffuse-2.X%2F2.8.5%2F&ts=1313661051&use_mirror=cdnetworks-kr-2
wget http://download.fedora.redhat.com/pub/epel/5/x86_64/python-ctypes-1.0.2-2.el5.x86_64.rpm

安装python-ctypes和fuse以及glusterfs

rpm -ivh python-ctypes-1.0.2-2.el5.x86_64.rpm
tar zxvf fuse-2.8.5.tar.gz && cd fuse* && ./configure && make && make install
tar zxvf glusterfs-3.2.2.tar.gz && cd glusterfs* && ./configure --enable-fusermount && make && make install

安装完成后会自动生成/etc/init.d/glusterd

将fuse模块放入到开机自动启动中

echo "modprobe fuse" > /etc/sysconfig/modules/fuse.modules
chmod 755 /etc/sysconfig/modules/fuse.modules
modprobe fuse

把glusterd加入到开机启动项中

chkconfig glusterd on

修改/etc/init.d/glusterd 文件

server端

#!/bin/bash
#
# chkconfig: 35 90 12
# description: Gluster File System service for volume management
#

# Get function from functions library
. /etc/rc.d/init.d/functions

BASE=glusterd
GLUSTERFSD=glusterfsd
GLUSTERFS=glusterfs
GLUSTERD_BIN=/usr/local/sbin/$BASE
GLUSTERD_OPTS="-l /var/log/glusterfs.log -f /usr/local/etc/glusterfs/glusterfsd.vol"
GLUSTERD="$GLUSTERD_BIN $GLUSTERD_OPTS"
RETVAL=0

# Start the service $BASE
start()
{
       echo -n $"Starting $BASE:"
       daemon $GLUSTERD
       RETVAL=$?
       echo
       [ $RETVAL -ne 0 ] && exit $RETVAL
}

# Stop the service $BASE
stop()
{
       echo -n $"Stopping $BASE:"
       killproc $BASE
       echo
       pidof -c -o %PPID -x $GLUSTERFSD &> /dev/null
       [ $? -eq 0 ] &&  killproc $GLUSTERFSD &> /dev/null

       #pidof -c -o %PPID -x $GLUSTERFS &> /dev/null
       #[ $? -eq 0 ] &&  killproc $GLUSTERFS &> /dev/null

       if [ -f /etc/glusterd/nfs/run/nfs.pid ] ;then
       pid=`cat /etc/glusterd/nfs/run/nfs.pid`;
       cmd=`ps -p $pid -o comm=`

       if [ $cmd == "glusterfs" ]; then
       kill `cat /etc/glusterd/nfs/run/nfs.pid`
       fi
       fi
}

### service arguments ###
case $1 in
 start)
       start
       ;;
 stop)
       stop
       ;;
 status)
       status $BASE
       ;;
 restart)
       $0 stop
       $0 start
       ;;
 *)
       echo $"Usage: $0 {start|stop|status|restart}."
       exit 1
esac

exit 0

client端

#!/bin/bash
#
# chkconfig: 35 90 12
# description: Gluster File System service for volume management
#

# Get function from functions library
. /etc/rc.d/init.d/functions

BASE=glusterd
GLUSTERFSD=glusterfsd
GLUSTERFS=glusterfs
GLUSTERD_BIN=/usr/local/sbin/$GLUSTERFS
GLUSTERD_OPTS="-l /var/log/glusterfs.log -f /usr/local/etc/glusterfs/glusterfs.vol /home/filecluster"
GLUSTERD="$GLUSTERD_BIN $GLUSTERD_OPTS"
RETVAL=0

# Start the service $BASE
start()
{
       echo -n $"Starting $GLUSTERFS:"
       daemon $GLUSTERD
       RETVAL=$?
       echo
       [ $RETVAL -ne 0 ] && exit $RETVAL
}

# Stop the service $BASE
stop()
{
       echo -n $"Stopping $GLUSTERFS:"
       killproc $GLUSTERFS
       echo
       pidof -c -o %PPID -x $GLUSTERFSD &> /dev/null
       [ $? -eq 0 ] &&  killproc $GLUSTERFSD &> /dev/null

       #pidof -c -o %PPID -x $GLUSTERFS &> /dev/null
       #[ $? -eq 0 ] &&  killproc $GLUSTERFS &> /dev/null

       if [ -f /etc/glusterd/nfs/run/nfs.pid ] ;then
       pid=`cat /etc/glusterd/nfs/run/nfs.pid`;
       cmd=`ps -p $pid -o comm=`

       if [ $cmd == "glusterfs" ]; then
       kill `cat /etc/glusterd/nfs/run/nfs.pid`
       fi
       fi
}

### service arguments ###
case $1 in
 start)
       start
       ;;
 stop)
       stop
       ;;
 status)
       status $BASE
       ;;
 restart)
       $0 stop
       $0 start
       ;;
 *)
       echo $"Usage: $0 {start|stop|status|restart}."
       exit 1
esac

exit 0

修改server端的/usr/local/etc/glusterfs/glusterfsd.vol, 这个配置就是在option bind-address 部分2台server会有所不同,其它全部一致

### file: server-volume.vol.sample

#####################################
###  GlusterFS Server Volume File  ##
#####################################

#### CONFIG FILE RULES:
### "#" is comment character.
### - Config file is case sensitive
### - Options within a volume block can be in any order.
### - Spaces or tabs are used as delimitter within a line.
### - Multiple values to options will be : delimitted.
### - Each option should end within a line.
### - Missing or commented fields will assume default values.
### - Blank/commented lines are allowed.
### - Sub-volumes should already be defined above before referring.

### Export volume "brick" with the contents of "/home/export" directory.
volume brick
  type storage/posix                   # POSIX FS translator
  option directory /home/filecluster        # Export this directory
end-volume
volume locker
  type features/posix-locks
  subvolumes brick
end-volume

### Add network serving capability to above brick.
volume server
  type protocol/server
  option transport-type tcp/server
# option transport-type unix
# option transport-type ib-sdp
 option bind-address 192.168.0.202     # Default is to listen on all interfaces # xen3上修改成192.168.0.203
# option listen-port 9999

# option transport-type ib-verbs
# option transport.ib-verbs.bind-address 192.168.1.10     # Default is to listen on all interfaces
# option transport.ib-verbs.listen-port 24016
# option transport.ib-verbs.work-request-send-size  131072
# option transport.ib-verbs.work-request-send-count 64
# option transport.ib-verbs.work-request-recv-size  131072
# option transport.ib-verbs.work-request-recv-count 64

# option client-volume-filename /etc/glusterfs/glusterfs-client.vol
  subvolumes brick
# NOTE: Access to any volume through protocol/server is denied by
# default. You need to explicitly grant access through # "auth"
# option.
  option auth.addr.brick.allow 192.168.0.* # Allow access to "brick" volume
  option auth.addr.locker.allow 192.168.0.* # Allow access to "locker" volume
end-volume

修改client端的/usr/local/etc/glusterfs/glusterfs.vol文件

### Add client feature and attach to remote subvolume
volume xen2
  type protocol/client
  option transport-type tcp/client
  option remote-host xen2
  option remote-port 24007
  option remote-subvolume locker       #name of the remote volume
end-volume

volume xen3
  type protocol/client
  option transport-type tcp/client
  option remote-host xen3
  option remote-port 24007
  option remote-subvolume locker
end-volume

#volume replicate2
#  type cluster/replicate
#  subvolumes xen2
#end-volume
#
#volume replicate3
#  type cluster/replicate
#  subvolumes xen3
#end-volume
#
volume bricks
  type cluster/replicate
  subvolumes xen2 xen3
#  subvolumes replicate1
end-volume
#
#volume writebehind
#  type performance/write-behind
#  option cache-size 1MB
#  subvolumes distribute
#end-volume
#
#volume cache
#  type performance/io-cache
#  option cache-size 64MB
#  subvolumes writebehind
#end-volume

最后就是启动server端的glusterd程序

/etc/init.d/glusterd start

然后启动client端的glusterd程序

/etc/init.d/glusterd start

这样你在client端用df就能看到如下这样的显示

[root@xen1 filecluster]# df -h
文件系统              容量  已用 可用 已用% 挂载点
/dev/sda1              29G  3.5G   24G  13% /
tmpfs                 512M     0  512M   0% /dev/shm
glusterfs#/usr/local/etc/glusterfs/glusterfs.vol
                       29G  3.3G   25G  12% /home/filecluster

然后我做了一个简单的跟NFS的对比测试

   1. NFSv4
         1. dd if=/dev/zero of=xen.img bs=1M count=500
            524288000 bytes (524 MB) copied, 13.9683 seconds, 37.5 MB/s
         2. dd if=/dev/zero of=xen.img bs=1M count=32
            33554432 bytes (34 MB) copied, 0.710816 seconds, 47.2 MB/s
   2. gluster
         1. dd if=/dev/zero of=xen.img bs=1M count=500
            524288000 bytes (524 MB) copied, 18.4192 seconds, 28.5 MB/s
         2. dd if=/dev/zero of=xen.img bs=1M count=32
            33554432 bytes (34 MB) copied, 0.591001 seconds, 56.8 MB/s

当然server端可以有2个以上的服务器来充当,但是由于我这里使用的是replication,所以用再多的服务器是比较浪费的,因为replication的模式下所有服务器的容量大小都是相同的。

gluster共提供以下几种模式

1. Distributed Volumes
2. Replicated Volumes
3. Striped Volumes
4. Distributed Striped Volumes
5. Distributed Replicated Volumes

一个系统上线必须要做一些故障测试。这里主要是对于服务器端的故障测试,因为到时候所有数据都是存储在服务器端的。我们就模拟在client写入的时候服务器端挂掉的情况
先是在客户端上执行一个大文件写入,这个时候我们关闭xen2上的glusterd程序

dd if=/dev/zero of=xen1.img bs=1M count=500

当客户端写入完成后我们看3台服务器上的xen1.img文件的大小

[root@xen1 filecluster]# ll
总计 512508
-rw-r--r-- 1 root root 524288000 08-24 15:33 xen1.img

[root@xen2 filecluster]# ll
总计 241652
-rw-r--r-- 1 root root 247201792 08-24 15:32 xen1.img

[root@xen3 filecluster]# ll
总计 512508
-rw-r--r-- 1 root root 524288000 08-24 15:33 xen1.img

我们可以看到xen2上的数据大小是不对的。然后我们启动xen2上的glusterd程序

当启动完成后我们看到的结果还是跟前面一样的。但是我们可以在client端执行

[root@xen1 filecluster]# ll

这样xen2上数据大小也正确了

但是我们不知道在有目录的情况这个方法是否还是可以。在client端执行

mkdir file
cd file
dd if=/dev/zero of=xen1.img bs=1M count=500

其它条件还是跟之前一样,发现如果是在/home/filecluster目录下执行ls的话,xen2上数据还是不正确的。
所以我们一旦发现某个server挂了之后必须执行如下命令才能完全同步

[root@xen1 filecluster]# find ./ -name "*" | xargs ls

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

《浪潮之巅》读后感

《浪潮之巅》是一本IT巨头的发展进程的图谱。看完的感受用一句话总结就是“各领风骚XX年”。

在AT&T时代和IBM时代还能领风骚几十年,但是发展到21世纪后发现这个缩短到只有几年了。特别是针对互联网领域。而吴军下一个google在哪里还是比较迷茫的,所以他去了腾讯。国内也就2个巨头阿里和腾讯。百度在技术和商业模式上跟这2家还是有一定差距的。

而新贵的崛起无疑是需要大量的人才的,google崛起的时候用了大量SUN和YAHOO的一些资深工程师,facebook崛起的时候又挖了大量google的人。在微薄上一个各个互联网公司互相挖人的动态。yahoo现在是只有被挖的份了。虽然它的薪资还是不错的。

在硅谷这个只占斯坦福大学1/10的土地上居然诞生了那么多的公司。我不知道硅谷的房租现在是怎么样的?是不是小公司也能租的起呢?但是国内的清华科技园还是中关村西区我看是很多还没融资到的小公司根本无法生存,大家都给房东打工而已。政府的目标就是提高准入标准,让那些小作坊全部关门。这个就让我想到静安区把吴江路拆了然后提高准入标准的事情。结果吴江路的小吃都没了。

另外一个重要的感想是美国对于知识产权的保护,这个是这些公司崛起的必备条件。要是没有保护,也许苹果的IPHONE没出多久就出来HIPHONE,intel的80386的芯片出来没多久就会出来90396这样的山寨货。而说到这个就涉及到整个社会的问题了,不展开了。

另外一个就是证明了那些定律的可怕性,摩尔定律推动着整个芯片行业的发展。而yahoo开创了互联网的免费模式,前段事件国内翻译过一本叫《免费:商业的未来》一书,可这个不就是说的是现在互联网基本的模式啊。而google是将这个发展到了极致,facebook要在营收上超过google那可不能在从现在的广告上突破了。必然发展自己的收费项目,比如象QQ币这样的了。

除了互联网,还有什么可以如此高速的发展。这个其实是由最早进入那几个公司来确定的。按书中的说法,如果互联网还是由AT&T这样的公司把持,那现在我们上网估计不会到处都是免费的资源了,开个邮箱要收费,发个QQ消息估计也得收费。可惜还好啊。

另外书中大量的关于如何融资的部分很不错,这个对于很多创业者是个很好的参考,以及后面上市应该怎么谈等等。然后金融业对于IT公司的影响力也太大了,不过影响力对于互联网公司还是以正面和积极的意义更多,对于一些硬件厂商就是负面的更多了。而一旦有更高速发展的行业,那互联网公司会被立刻抛弃的。

互联网的常青树至今没有出现,要有可能现在也就google看着会更像一点。

一个国家如何常青树也是同样的道理。社会契约是很重要的,亚当斯密不光写了著名的《国民财富的性质和原因的研究》,其实他还写了一本《道德情操论》我们可以看看,在我20岁的时候我觉得看不大懂。

但是如何在知识产权保护和阻止垄断是当务之急啊。要不然我们会被微软这样的公司继续摆刀。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

Engineering Reliability into Web Sites: Google SRE

Engineering Reliability into Web Sites: Google SRE

Alex Perry

alex.perry

原文:http://research.google.com/pubs/archive/32583.pdf

概要

这个主要讲的是在google的网站保障工程师(SRE, 国内应该称之为应用运维),解释了他的目标和描述它会遇到的挑战

在mountain view, zurich, new york, santa monica, dublin 以及 kirkland的SRE团队管理着许多google的服务和网站。

他们利用分布于全世界数据中心的基于linux的计算资源。

主要内容

  • 根据不同站点来划分组
  • 网站的失效和不可靠会耗尽人力成本
  • 工程师应该专注于消除未来的工作,而不是像救火队员一样,要有一定的预见性。
  • 一个新项目是如何转移到SRE团队的。这个主要是一个新项目是如何从开发转到SRE的。
  • 对于用户量的快速增长要有计划。主要是根据现有的增长速度来进行预测。
  • 估算SRE团队最合理的人数

网站 — 是一项综合的部署

  1. 团队需要确定用户可视化的(可测量的)的在线时间和质量水平
    1. 这个需要掌控所有相关软件和系统的情况
  2. 对于各个组件有深度的了解和知识是很有必要的
    1. 这是一个需要比较陡的学习曲线,这种曲线大部分由于各个组件的复杂性造成的
    2. 要持续的再学习,因为网站是一直都在升级的。要想一劳永逸是不大现实的。
  3. 对于使用共享组件架构的特殊性
    1. 要确定那些共享的组件有很好的可靠性。比如一个网站所用共享的中间层和底层组件。

Reliability – it just works

  1. 最小化的人力成本的使用
    1. 团队管理监控和开发都需要自动化。自动化监控和部署。比如puppet,nagios这些工具
    2. 这个意味着使用脚本工具和数据分析工具。一些初始化脚本和安装工具等等。
    3. 大部分失效都需要适当地自动恢复。当出现问题了能够自动恢复。比如自动切换和重启。
  2. 把更高的风险转移到方便处理的时候
    1. 在工作日之前学习那些已经处理掉的风险(Learn of age mortality risk during preceding workday)
    2. 那些刚开始的风险需要完美的解决,防止影响google现有的业务(Infant mortality ideally also avoids Google meals)

工程师—不是管理员

  1. 对于报警和通知规范需要细致的定义
    1. 在发出通知之前可能错误已经导致了问题。
    2. 通常定义报警和通知规范需要通过多个层次,多个级别,多个角度进行。这个主要是从多个维度来定义。
    3. 这些定义可以通过设计来手动和自动的进行增加。这个就需要自动化的管理平台
  2. 对于项目的升级和扩展进行负责
    1. 计划所有的需求,同时要重视效率。
    2. 文件的bug可以在合适的时候进行修复。

新思维: SRE是兼职的开发人员

  1. 一般工程师都会一周抽一天去做开发
    1. 在其它地方可能会就要利用晚上或者周末时间。
    2. Google的工程师每天都有20%的时间来做这些项目。
  2. 开发者有时候会有其它的想法
    1. 有多少老的网站的工作是需要快速回退的。
    2. SRE有20%的空余时间来做项目,这些项目有趣吗?

最初,网站是需要重点维护的

  1. SRE给出可以自动化的日常事务的指导
    1. 通过消除重复性的工作来减少工作负荷。
  2. SRE指出开发文档中的错误和疏忽,但是我觉得这个最好在开发阶段就指出来。
    1. 开发人员也许会在其它地方也同样给你帮助。
  3. SRE建议附加的长期的监控
    1. 这些建议应该覆盖所有的间隙和跟踪性能。
    2. 管理员需要充分的可信赖的监控。

上线一个新网站是一个契机

  1. 你不要对那些新上线的20%的网站而后悔
    1. 页面调度器可以发出比你想象的更多的警告(一般情况下网站会在任何时候发出警告)
  2. 但是在上线的几周内,SRE的专业知识是很有必要的
    1. 开发人员的工作压力可能降低到1%
  3. 剩余的1%可以在任何时候做
    1. 仅仅写好好的文档可以让别人方便接管
    2. 许多工程师都选择继续使用页面调度器

把网站推给了SRE

  1. 这个决定是逐步变为长期的
    1. 对于一个网站的日常工作会变得减少
    2. 通过优化和分析可以使软件逐步改进
  2. 开发人员仍然会保留很少的关注对于这个网站
    1. 工作主要对针对下一个版本,修复已知的bug
    2. 老的在线的版本会逐渐不重视了
    3. 一个明显的特征就是把这些网站推到SRE这边来进行维护了

on call – more than quick fixes

  1. SRE团队人员需要轮流值班
    1. 修复那些现在还不能自动修复的问题
    2. 通过累计发生的问题来确认优先级
    3. 把诊断的问题和解决方案进行文档话
  2. 一个永久的解决方案需要很长的时间才能完成
    1. 发现文件bug,开发补丁,测试,代码复查,提交
    2. 集成,版本和发布要进行日程安排
    3. 为什么要花大量的时间来做这些呢? 这个主要让SRE的变的更有条理。对于类似X度这样的公司整个运维部门整天就是忙上线实在是无语。

名声 – 越来越多的用户

  1. 网站的稳定性不能由于升级而降低
    1. 网站架构通常是可伸缩性和健壮的
    2. 这些是google软件工程师的核心技能。
  2. 算法的性能是成比例的扩大的
    1. 所以修复bug也要监控和自动操作
  3. 实际上工作压力是随着问题的增加而增加的
    1. 有效的人力确实被现有人数限制着的

事情的增加 — 更多的用户

  1. 工程问题可能会根据用户等比例的放大
    1. 软件中新的功能没有被完全实现。O(1)
    2. 在常规的硬盘挂掉导致服务器down掉。O(u)
    3. 内存中的宇宙射线,新用户的哈希是有效的。O(u2) 这个意思就是说由于算法的问题,导致本来2个用户应该是不一样的哈希结果,但是却变成一样了。这一般要到非常大的用户量才会发生。
    4. 以太网中的比特传输是无序的,所有包都是通过CRC校验的。O(u3) 这个的意思是由于网络流量非常大,以及并发特别高。导致CRC校验也会产生冲突。这得多大流量啊!!!
  2. 更高等级的请问题通常不太可能一开始就发生
    1. 因为他们是有可能发生的,但是是无形的,因此很难被修复。
    2. 但是它们发生后会使问题扩散的很快。

第一次出现 — 对于每一个小时

  1. 想象每10天用户数量就会翻倍
  2. 考虑网站的O(u3)问题
    1. 瞬时的页面比例 = exp(date /5)/k
    2. 累计的页面访问数量 = exp(date/5)5/k
  3. 在你收到第一个页面产生的问题
    1. 期望的第一个页面的时间 = 5 in (k/5)
    2. 在未来的3个星期内,它会每小时报告一次。

多久可以扩展一个网站

  1. 这个主要是看解决问题的决心
    1. 多长时间可以确定问题,并且一个一个解决
  2. 要早期的发现bug需要好的工具
    1. 远程诊断和相关维护的日志
    2. 在发现第2个警告前就要开始解决第一个问题。
  3. 一次就修复bug,这个需要快速地测试
    1. 确认以前的bug不会复现

false positives, false negatives

  1. 谨慎小心的报警会导致一个危机
    1. 导致在压力下会一有问题立即去修复。
    2. 这相反会消耗工程师的时间和精力。因为报警过于琐碎而浪费了工程师的精力。
  2. 通过对于归档数据的分析进行优化
    1. 监控系统通常是不出声的。(正常的时候当然不会报警呀)
    2. 新增加的问题会更容易被发现
    3. 一般问题马上会被侦测到,那网站会变的更快

轻量的SRE团队(Lower bound on SRE team size)

  1. 每周的一天:做自己的项目,就是那些20%没被分配的时间
  2. 每周的1天: 休息,公司事务, 志愿者,或者病假
  3. 每周的1天: 对于网站的特别培训, 学习网站的更改信息
    1. 所有的每个网站培训都是相同的对于团队大小。
  4. 每周的2天: 网站分析,计划相关内容,维护等等
    1. 对于一个网站来说每周需要多少人力?
    2. 这个是确定团队人数的低的边界。

估算on call能覆盖哪些需求

  1. 工程师能否对于一个警告不响应
    1. 如果是,那我们需要实现工程师冗余
  2. 你网站页面服务的失效比例是多少
    1. 有可能会超过10%,很难达到1%
    2. 5%会使用4种冗余的方法来达到99.999%
  3. 对于任何一个报警只能有一个工程师响应
    1. 使用优先级或者选举的手段来避免浪费精力。
    2. 那其它ON CALL的SRE不会感到困扰

网站是否需要合并

  1. 比较网站的工程操作和oncall需求
    1. 可能会让一个SRE团队来对多个网站值班
    2. 培训开销:每个工程师都要学习所有负责的网站
  2. 这种合并整合是一个长期的目标
    1. 有一些观点是,每个网站都会最终停止更新
    2. 然后工程师专门对付较低优先级的问题
    3. 比如一个网站,最终维护的趋势是变为0
    4. 但是覆盖需求的on call人员是固定不变的。

总结:

  1. 网站的有效性是需要不间断的工程性 的努力
    1. 这个比软件实现需要更长的时间段
    2. 工作要有短期目标和长期目标是非常重要的
  2. 大型网站需要一个管理员团队
    1. 如果他们一直都很忙,那就没有空间成长
    2. 让一个团队管理多个网站是比较经济的
  3. 撰写和修改软件来替代管理工作
    1. 随着网站的扩展自动化的好处会越来越多
  4. 团队尽量要小,每个团队都有一个合适的大小

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com

twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA

态度问题

上周去人民医院看病,这医生的态度就是敷衍。

周六9点去的,到了之后挂号还是挺快。然后就是等啊等的。由于是周六门诊,所以一个科室都是只有一个医生看病。

而这个医生的态度绝对是有问题。前面看到很多病人都是不到1,2分钟就被打发出来了。我想我应该不会也被这样对待吧。

结果我发现我比他们还快,说了下病情,医生就说这个是什么病。也不按任何部位,也不说要检查一下,就这样直接了当的说了。然后叉叉叉的开始开药方了。我不死心就问,这个是什么原因导致的,医生回答说这个原因是有很多种的,具体哪种不清楚。

我觉得吧,这个看病确实不是都靠仪器检查的,有些医生巴不得你把他们科室所有检查科目都给做了再给你诊断。这种医生也太黑了,而象我碰到这样的,简直就是敷衍了事,巴不得快下班了。也不仔细查看,也不详细问病情或者各种症状。然后直接就给你下结论了,我不知道是你觉得这种是小毛病,不值得你看呢,还是你觉得你看的同样的病太多直接一眼就能确诊了呢。

至少给我的感觉是这个医生很不专业,也不问什么问题,望闻问切在你这边就是个空话。

前几天看到一个妇产科大夫的月薪才2500了,想想也是阿,要在北京一个月2500能干什么。但是这就能算是上班捣浆糊的理由了吗?

一个对于自己的职业如此的不认真和负责,那他会有什么发展呢? 如果是让患者来评判的话他估计这辈子只能当个这样的医生了。

其实我之前也碰到过这种类似的医生,同一个病,在不同医生看来居然是完全不同的病,最终还是华山医院一个副教授给确诊了,在医院躺了一个礼拜就回家了,什么事情都没有。也许这就是水平吧。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin & MySQL DBA