使用自动构建系统
原则：
    一次按键就解决问题，使用完全自动化（“单操作”）的构建系统，无需拥护干预即可构建整个项目。
讨论：
    构建有2种模式：增量构建和完全构建。增量构建只重新构建上次构建（可以是增量的或者是完全的）以来发生变化的部分。注意：两次连续增量构建中的第二次构建不应该编写任何输出文件；否则坑内会出现依赖循环，构建系统也可能会执行不必要的操作。
    一个项目的完全构建可能有不同形式。可以考虑通过改变许多基本特性，调整构建过程的参数，候选的特性包括目标架构，调试模式还是发布模式，以及范围（基本文件、所有文件、还是完整的安装文件）。一种构建设置能够生成产品的基本可执行文件和库，另一种设置可能还会生成附属文件，而完全构建则可能生成包括所有文件、第三方可重发行文件和安装代码在内的安装文件。
    随着项目的日渐发展，不使用自动构建所带来的成本也会逐渐增加。如果没有从一开始就使用自动构建，时间和资源的浪费就将无可避免。更糟糕的情况是，到了不得不使用自动构建的时候，你所面临的压力将比项目开始时大得多。
    这一块一直没有注意，以后要切记，使用自动构建系统。

目前很多企业信息化系统都有自己的监控平台和监控手段，无论是采用哪种手段去实现对系统的实时监控和故障告警，大多采用的方式也只有两种：一、集中式监控和分布式监控。博主根据自身公司监控存在的问题，总结了一些经验并提出一些在监控平台建设建议以供大家参考学习，如有考虑不周的地方还希望大家多多批评指正哦。

为了更好、更有效的保障系统上线后的稳定的运行。对于服务器的硬件资源、性能、带宽、端口、进程、服务等都必须有一个可靠和可持续的监测机制，统计分析每天的各种数据，从而能及时反映出服务器哪里存在性能瓶颈、安全隐患等。另外是要有危机意识，就是了解服务器有可能出现哪些严重的问题，出现这些问题后该如何去迅速处理。比如数据库的数据丢失，日志容量过大，被黑客入侵等等。

一、上线之前的准备工作

1.       首先是备份，做好定时备份策略，备份所有你认为重要的数据，并且定期检查你的备份是否有效、全面；

2.       日志轮换，无论你想用哪种轮换方式，控制日志增长避免驱动器已满是你的目的；

3.       做一定的安全措施，如防火墙iptables的访问控制，用denyhosts防止黑客远程暴力破解；

4.       mysql远程登录权限等等；

5.       最后就是服务器、网元设备的监控。

二、监控策略

1.       定义告警优先级策略

一般的监控到的结果是成功或者失败，如Ping不通、访问网页出错、连接不到Socket，发生时这些称之为故障，故障是最优先的告警。除此之外，还能监控到返回的延时、内容等，如Ping返回的延时、访问网页的时间、访问网页取到的内容等。利用返回的结果可以自定义告警条件，如Ping监控的返回延时一般是10-30ms之间，当延时大于100ms时候，表示网络或者服务器可能出现问题，引起网络响应慢，需要立即检查是否流量过大或者服务器CPU太高等问题。

2.       定义告警信息内容标准

当服务器或应用发生故障时告警信息内容非常多，如告警运行业务名称、服务器IP、监控的线路、监控的服务错误级别、出错信息、发生时间等。预先定义告警内容及标准使收到的告警内容具有规范性及可读性。这点对于用短信接受告警内容特别有意义，短信内容最多是70个字符，要在70个字符完全知道故障内容比较困难，更需要预先定义内容规范。如：“视频直播服务器10.0.211.65 在2012-10-18 13:00电信线路监控第到1次失败”，清晰明了的知道故障信息。

3.       通过邮件接收汇总报表

每天收到一封网站服务器监控的汇总报表邮件，花个两三分钟就大致了解网站和服务器状态。

4.       集中监控和分布式监控相结合

主动（集中）监控虽然能不需要安装代码和程序，非常安全和方便，但缺少很多细致的监控内容，如无法获取硬盘大小、CPU的使用率、网络的流量等，这些监控内容非常有用，如CPU太高表示有网站或者程序出问题，流量太高表示可能被攻击等。



被动（分布式）监控常用的是SNMP(简单网络管理协议)，通过SNMP能监控到大部分你感兴趣的内容。大部分操作系统支持SNMP，开通管理非常方便，也非常安全。SNMP缺点是比较占用带宽，会消耗一定的CPU和内存，在CPU太高和网络流量大情况下，无法有效进行监控。

5.       定义故障告警主次

对于监控同一台服务器的服务，需要定义一个主要监控对象，当主要监控对象出现故障，只发送主要监控对象的告警，其它次要的监控对象暂停监控和告警。例如用Ping来做主要监控对象，如果Ping不通出现Timeout，表示服务器已经当机或者断网，这时只发送服务器Ping告警持续监控Ping，因为再继续监控和告警其它服务已经没有必要。这样能大大减少告警消息数量，又让监控更加合理、更加有效率。

本地监控脚本的规范化部署

6.       对在本地部署的监控脚本要进行统一规范的部署并记录到KM系统。

7.       实现对常见性故障业务自我修复功能

实现对常见性故障业务自我修复功能脚本进行统一部署并对修复后故障进行检查告警检查频次不多于3次。

8.       对监控的业务系统进行分级

一级系统实现7*24小时告警，二级系统实现7*12小时告警，三级系统实现5*8小时告警。

9.       监控范围及目标

实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理；同时自动收集、过滤、关联和分析各种管理功能产生的故障事件，实现对故障的提前预警和快速定位；对网络和业务应用等IT资源的性能进行监控，定期提供性能报表和趋势报表，为性能优化及未来系统扩容提供科学依据。

通常情况下，我们可以将监控对象这么来分：

l  1.服务器监控，主要监控服务器如：CPU 负载、内存使用率、磁盘使用率、登陆用户数、进程

l  状态、网卡状态等。

l  2.应用程序监控，主要监控该应用程序的服务状态，吞吐量和响应时间，因为不同应用需要监

l  控的对象不同，这里不一一列举。

l  3.数据库监控，只所以把数据库监控单独列出来，足以说明它的重要性，一般监控数据库状态，

l  数据库表或者表空间的使用情况，是否有死锁，错误日志，性能信息等等。

l  4.网络监控，主要监控当前的网络状况，网络流量等。

以上四条应该算是最基本的，也是保证网站正常运行必须要知道的几点内容，这样才能实现我们常说的“运筹帷幄之中，决胜千里之外”。

目录

规范分别从上线前，上线中，上线后三个阶段：

上线前：

上线中：

上线后：

规范分别从上线前，上线中，上线后三个阶段：


上线前：

1、  确保测试环境及预发布环境测试通过，才允许上线；

2、  提前知晓关联系统负责人关注各自系统（以咚咚或邮件的方式）；

3、  提前梳理好本次上线需要修改的配置文件等信息，提醒开发进行配置备份；

4、  提前准备好本次上线验证所需的测试数据，线上测试商品必须打测试标识，且在测试分类下（必须使用白名单下单）；

上线中：

1、  测试和开发必须结对上线；

2、  监督开发需先下线机器，再进行任务发布；

3、  单台机器验证通过后，才允许开发对该分组下的其他机器进行任务发布；

4、  以分组为单位，依次进行上线操作；

5、  上线功能着重测试，关联的核心系统和业务场景必须回归测试；

6、  线上功能验证的同时，提醒并监督开发实时关注后台日志及系统情况；

7、  配置文件修改上线，必须监督至少两名开发人员一起检查修改配置信息；

8、  实时关注后台日志，若出现报错、异常等情况，立即通知相关开发人员迅速定位问题；

9、  实时监控risk数据信息，若出现业务量下降等情况，立即通知相关开发人员迅速定位问题；

10、 重点关注UMP关键监控点的调用次数、可用率、性能、端口存活等情况；

11、 重点关注JSF接口是否正常；

12、 若涉及JMQ，则重点关注消息是否有积压、重试等情况；

13、 若上线导致重大影响，需要求开发立即进行回滚；

上线后：

1、  进行整体系统流程验证；

2、  持续关注UMP、Risk、JSF、JMQ、后台日志等相关监控系统信息（至少15分钟），各系统监控信息均保持平稳，则代表上线成功；

3、  邮件回复或通报本次成功上线的内容；

4、  评估上线过程中测试所用的数据是否需要还原或清除；

protected-broadcast 系统应用自定义广播规范



一、android:sharedUserId=”android.uid.system”

系统中所有使用android.uid.system作为共享UID的APK，都会首先在manifest节点中增加 android:sharedUserId=”android.uid.system”，然后在Android.mk中增加 LOCAL_CERTIFICATE := platform.如Settings，:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:androidprv="http://schemas.android.com/apk/prv/res/android"
    package="com.android.settings"
    coreApp="true"
    android:sharedUserId="android.uid.system"
    android:versionCode="1"
    android:versionName="1.0" >

下面所说的系统应用也是指这些shareUID是system的应用。

在开机PMS初始化的时候，将该name为“android.uid.system”的uid归为1000的system用户ID；
PackageManagerService.java
public PackageManagerService(Context context, Installer installer,
        boolean factoryTest, boolean onlyCore) {
            ...
            mSettings.addSharedUserLPw("android.uid.system", Process.SYSTEM_UID,
               ApplicationInfo.FLAG_SYSTEM, ApplicationInfo.PRIVATE_FLAG_PRIVILEGED);
            ...
}



Process.java
/**
* Defines the UID/GID under which system code runs.
*/
public static final int SYSTEM_UID = 1000;



二、AMS对系统应用发出的广播进行安全检查

当应用或者组件发送广播时，在广播发送的必经之路上，AMS对系统应用发送的广播进行了检查：  



1. 判断是否是系统uid，



ActivityServiceManager.java
final int broadcastIntentLocked(){
final boolean isCallerSystem;
switch (UserHandle.getAppId(callingUid)) {
//说明是以下几个uid的进程都认为是system应用进程
    case Process.ROOT_UID:
    case Process.SYSTEM_UID:
    case Process.PHONE_UID:
    case Process.BLUETOOTH_UID:
    case Process.NFC_UID:
        isCallerSystem = true;
 break;
 default:
        isCallerSystem = (callerApp != null) && callerApp.persistent;
 break;
}
}

这里需要注意的是除了SYSTEM_UID被认为是系统uid，还有ROOT_UID，PHONE_UID，BLUETOOTH_UID，NFC_UID， 

需要特别注意的是如果都未定义以上的UID，但应用的AndroidManifest.xml中定义了persistent属性为true，即常驻应用，也会被设定为由系统调用，同样需要进行广播的权限检查。



2. 如果是SYSTEM_UID，便对该广播进行安全检查：



if (isCallerSystem) {
       checkBroadcastFromSystem(intent, callerApp, callerPackage, callingUid,
                        isProtectedBroadcast, receivers);
}



3. 在checkBroadcastFromSystem()函数中进行安全检查：



private void checkBroadcastFromSystem(Intent intent, ProcessRecord callerApp,
            String callerPackage, int callingUid, boolean isProtectedBroadcast, List receivers) {
        final String action = intent.getAction();
        if (isProtectedBroadcast  //A如果是受保护的广播或者特殊的公共广播
                || Intent.ACTION_CLOSE_SYSTEM_DIALOGS.equals(action)
                || Intent.ACTION_DISMISS_KEYBOARD_SHORTCUTS.equals(action)
                || Intent.ACTION_MEDIA_BUTTON.equals(action)
                || Intent.ACTION_MEDIA_SCANNER_SCAN_FILE.equals(action)
                || Intent.ACTION_SHOW_KEYBOARD_SHORTCUTS.equals(action)
                || Intent.ACTION_MASTER_CLEAR.equals(action)
                || AppWidgetManager.ACTION_APPWIDGET_CONFIGURE.equals(action)
                || AppWidgetManager.ACTION_APPWIDGET_UPDATE.equals(action)
                || LocationManager.HIGH_POWER_REQUEST_CHANGE_ACTION.equals(action)
                || TelephonyIntents.ACTION_REQUEST_OMADM_CONFIGURATION_UPDATE.equals(action)
                || SuggestionSpan.ACTION_SUGGESTION_PICKED.equals(action)) {
            // Broadcast is either protected, or it's a public action that
            // we've relaxed, so it's fine for system internals to send.
            return;
        }

        // This broadcast may be a problem...  but there are often system components that
        // want to send an internal broadcast to themselves, which is annoying to have to
        // explicitly list each action as a protected broadcast, so we will check for that
        // one safe case and allow it: an explicit broadcast, only being received by something
        // that has protected itself.
        //如果该广播收接收者，且指定了接收者的包名或者组件名
        if (receivers != null && receivers.size() > 0
                && (intent.getPackage() != null || intent.getComponent() != null)) {
            boolean allProtected = true;
            for (int i = receivers.size()-1; i >= 0; i--) {
                Object target = receivers.get(i);
                if (target instanceof ResolveInfo) {
                    ResolveInfo ri = (ResolveInfo)target;
                    //如果接收者exported设置为false或者接收者设置了权限，则说明做了保护，allProtect为Ture
                    if (ri.activityInfo.exported && ri.activityInfo.permission == null) {
                        allProtected = false;
                        break;
                    }
                } else {
                    BroadcastFilter bf = (BroadcastFilter)target;
                    if (bf.requiredPermission == null) {
                        allProtected = false;
                        break;
                    }
                }
            }
            if (allProtected) {
                // All safe!
                return;
            }
        }
        //C 这里会打出wtflog，同时在dropbox中会生成wtf文件
        // The vast majority of broadcasts sent from system internals
        // should be protected to avoid security holes, so yell loudly
        // to ensure we examine these cases.
        if (callerApp != null) {
            Log.wtf(TAG, "Sending non-protected broadcast " + action
                            + " from system " + callerApp.toShortString() + " pkg " + callerPackage,
                    new Throwable());
        } else {
            Log.wtf(TAG, "Sending non-protected broadcast " + action
                            + " from system uid " + UserHandle.formatUid(callingUid)
                            + " pkg " + callerPackage,
                    new Throwable());
        }
    }



1. framework中声明的保护广播和一些放开的公共广播：



isProtectedBroadcast = AppGlobals.getPackageManager().isProtectedBroadcast(action);

isProtectedBroadcast为true则代表该广播在Framework/base/core/res/AndroidManifest.xml中有声明为保护广播,这样的广播只能由系统发出。如果是phone进程的，一般在Teleservice下的AndroidManifest.xml中声明保护广播。 如果是系统应用，则可以在系统应用的AndroidManifest.xml里有声明为保护广播。 



<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android" coreApp="true" android:sharedUserId="android.uid.system"
    android:sharedUserLabel="@string/android_system_label">
    <!-- ================================================ -->
    <!-- Special broadcasts that only the system can send -->
    <!-- ================================================ -->
    <eat-comment />

    <protected-broadcast android:name="android.net.tether.CONNECTEDSTA_CHANGE" />
    <protected-broadcast android:name="android.intent.action.SCREEN_OFF" />
    <protected-broadcast android:name="android.intent.action.SCREEN_ON" />
    ...
    <protected-broadcast android:name="android.intent.action.PRE_BOOT_COMPLETED" />

    ...
</manifest>

另外一些公共的action，虽然没有保护但是系统允许在系统内部发送；如Intent.ACTION_CLOSE_SYSTEM_DIALOGS，Intent.ACTION_DISMISS_KEYBOARD_SHORTCUTS等；



2. 未在Framework中声明保护广播或者非放开的公共广播

B处的大意是经常有系统组件想发送内部广播给自己，如果必须明确列出每个动作作为受保护的广播是很烦人的，因此在这里进行安全检查，如果符合安全条件及可以正常发送；如果不满足安全条件，则就会走到C处，打印wtf log。wtf的意思是What a Terrible Failure: Report an exception that should never happen. 

虽然检查不安全但是系统还是会允许发送该广播，logcat中会出现这样的提醒log：



Sending non-protected broadcast xxxxx from system 7747:com.xxxx.xxxx/1000
                                                                     pkg com.xxxxx.xxxxx



3. 未给广播加保护影响

虽然广播正常发送了，不影响广播的作用，但是这样的使用是不安全的，系统组件自定义的广播可能会被恶意软件接收或者发送，导致系统不稳定。  

且在这个log打印同时会在系统的dropbox下新生成一个wtf的log文件，发多少条这样的广播，就生成多少个这样的文件。而dropbox中默认最多只有1000个文件，再多了就会冲掉旧的文件。Dropbox是我们用于分析ANR tombstone等问题的重要log来源，因此会严重影响稳定性同事对该类问题的统计和解决。  

为了提高系统的安全性且避免这样的log，系统应用组件当在使用自发自收的广播时，要尽可能使用明确的广播，及指定接收的包名或者组件名，且对广播发送和接收加权限保护。同时这也使我们使用广播更加规范。



三、整改举例：

如果该广播是an explicit broadcast，且该receiver的android：exported为false，或者ri.activityInfo.permission!=null,及该receiver加了权限保护，系统则认为这个广播时做过保护了的，予以正常发送，便不会打这个log，是个规范使用的广播。

动态广播，系统应用可以使用本地广播进行操作，可以满足检查安全的需求。
静态广播： 

a.如果是系统独立应用的广播，可以在应用的AndroidManifest.xml里声明为保护广播就可以了。不过注意验证的时候，需要使用adb push到system/app或者system/priv-app/下再重启安卓验证；使用adb install -r后验证依然会报未保护提醒。
================== 
PS: 

adb install 和adb push区别在于，adb install会将应用安装在data/app下，而adb push到system/priv-app下即安装在system/priv-app下，adb install和adb push重启后都会有一个扫描解析apk的动作

pkg = pp.parsePackage(tmpPackageFile, parseFlags);
最终调到：
private Package parseBaseApkCommon(){}

在parseBaseApkCommon()函数中：

//frameworks\base\core\java\android\content\pm\PackageParser.java
private Package parseBaseApkCommon(Package pkg, Set<String> acceptedTags, Resources res,
            XmlResourceParser parser, int flags, String[] outError) throws XmlPullParserException,
            IOException {
     while ((type = parser.next()) != XmlPullParser.END_DOCUMENT
                && (type != XmlPullParser.END_TAG || parser.getDepth() > outerDepth)) {
     if(...){...
     } else if (tagName.equals(TAG_PROTECTED_BROADCAST)) {
                sa = res.obtainAttributes(parser,
                        com.android.internal.R.styleable.AndroidManifestProtectedBroadcast);
                String name = sa.getNonResourceString(      com.android.internal.R.styleable.AndroidManifestProtectedBroadcast_name);
                sa.recycle();
                if (name != null && (flags&PARSE_IS_SYSTEM) != 0) {//如果不是system的parser flag就跳过解析
                    if (pkg.protectedBroadcasts == null) {
                        pkg.protectedBroadcasts = new ArrayList<String>();
                    }
                    if (!pkg.protectedBroadcasts.contains(name)) {
                        pkg.protectedBroadcasts.add(name.intern());
                    }
                }
                XmlUtils.skipCurrentTag(parser);
            }
     }
     ...
}

在system/priv-app下扫描apk是是PARSE_IS_SYSTEM的 flag(在开机时的PMS的构造函数里就设置了扫描系统应用文件夹的parser flag)，而data/app下没有这个system的parser flag 

因此在这里adb push可以生效，adb install未生效。

==========

b. 使用指定包名并且加权限保护 

b1.在Androidmanifest.xml里声明receiver的时候加上自定义的权限，如果是仅需应用内接收，可以将android:exported属性设置为false；

        <receiver android:name=".DemoReceiver"
            android:exported="false"
            android:permission="com.android.permission.RECV.XXX">
            <intent-filter android:priority="1000">
                <action android:name="com.android.demo.test.XXX"/>
            </intent-filter>
        </receiver>

具体加权限请参考 http://blog.csdn.net/javensun/article/details/7334230 

b2. 发送广播的地方指定包名或者组件名



Intent i = new Intent("com.android.demo.test.XXX");
i.setPackage("com.XXX.broadcasttest");
sendBroadcast(i,"com.android.permission.RECV.XXX");

注意指给广播加权限是不够的，在checkBroadcastFromSystem对未在framework中声明为保护广播的系统应用自定义广播进行安全检查的前提是这是一个explicit的广播。因此满足上面两步后才能真正消除警告的wtf log.  

c. 如果是非独立应用的系统组件，或者是framework下的应用使用的广播，推荐在framework/base/core/res/AndroidManifest.xml中有声明为保护广播。

android exported属性：http://blog.csdn.net/watermusicyes/article/details/46460347 

广播权限限制：http://blog.csdn.net/javensun/article/details/7334230 

本地广播使用：http://blog.csdn.net/lj2012sy/article/details/51688985