• CMDB资源配置管理项目

    浅谈ITIL

    TIL即IT基础架构库(Information Technology Infrastructure Library, ITIL，信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订，现由英国商务部OGC(Office of Government Commerce)负责管理，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。

    1、事件管理（Incident Management）

    事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到服务级别协议所定义的服务级别。

    2、问题管理（Problem Management）

    问题管理是指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因，并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理流程。与事故管理强调事故恢复的速度不同，问题管理强调的是找出事故产生的根源，从而制定恰当的解决方案或防止其再次发生的预防措施。

    3、配置管理（Configuration Management）

    配置管理是识别和确认系统的配置项，记录和报告配置项状态和变更请求，检验配置项的正确性和完整性等活动构成的过程，其目的是提供IT基础架构的逻辑模型，支持其它服务管理流程特别是变更管理和发布管理的运作。

    4、变更管理（Change Management）

    变更管理是指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。变更管理的目标是确保在变更实施过程中使用标准的方法和步骤，尽快地实施变更，以将由变更所导致的业务中断对业务的影响减小到最低。

    5、发布管理（Release Management）

     发布管理是指对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程。发布管理以前又称为软件控制与分发

     

    事件管理的目标是在不影响业务的情况下，尽可能快速的恢复服务，从而保证最佳的效率和服务的可持续性。事件管理流程的建立包括事件分类，确定事件的优先级和建立事件的升级机制。

    问题管理是调查基础设施和所有可用信息，包括事件数据库，来确定引起事件发生的真正潜在原因，一起提供的服务中可能存在的故障。

    配置管理的目标是：定义和控制服务与基础设施的部件，并保持准确的配置信息。

    变更管理的目标是：以受控的方式，确保所有变更得到评估、批准、实施和评审。

    发布管理的目标是：在实际运行环境的发布中，交付、分发并跟踪一个或多个变更。

    服务台：服务台是IT部门和IT服务用户之间的单一联系点。它通过提供一个集中和专职的服务联系点促进了组织业务流程与服务管理基础架构集成。服务台的主要目标是协调客户（用户）和IT部门之间的联系，为IT服务运作提供支持，从而提高客户的满意度。

    CMDB介绍

    CMDB --Configuration Management Database 配置管理数据库, CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

    在实际的项目中，CMDB常常被认为是构建其它ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。
    70%～80%的IT相关问题与环境的变更有着直接的关系。实施变更管理的难点和重点并不是工具，而是流程。即通过一个自动化的、可重复的流程管理变更，使得当变更发生的时候，有一个标准化的流程去执行，能够预测到这个变更对整个系统管理产生的影响，并对这些影响进行评估和控制。而变更管理流程自动化的实现关键就是CMDB。
    CMDB工具中至少包含这几种关键的功能：整合、调和、同步、映射和可视化。
    • 整合是指能够充分利用来自其他数据源的信息，对CMDB中包含的记录源属性进行存取，将多个数据源合并至一个视图中，生成连同来自CMDB和其他数据源信息在内的报告；
    • 调和能力是指通过对来自每个数据源的匹配字段进行对比，保证CMDB中的记录在多个数据源中没有重复现象，维持CMDB中每个配置项目数据源的完整性；自动调整流程使得初始实施、数据库管理员的手动运作和现场维护支持工作降至最低；
    • 同步指确保CMDB中的信息能够反映联合数据源的更新情况，在联合数据源更新频率的基础上确定CMDB更新日程，按照经过批准的变更来更新 CMDB，找出未被批准的变更；
    • 应用映射与可视化，说明应用间的关系并反应应用和其他组件之间的依存关系，了解变更造成的影响并帮助诊断问题。

    并且在做自动化的前提是标准化，我们在做CMDB的时候就相当于做标准化的过程，并能仅仅告诉研发和运维同学怎么怎么做，如果没有一个系统强制要求他这样做那么之前的流程和标准对于运维和研发来说他们已经习惯了，是很难实施的！

    自动化的前提就是标准化和流程化！

    CMDB自定义用户认证

    自己创建一个表,做一个one-to-one去管理User表,相当于扩展它!就相当于有两张表.一个是Django自带的表一个是我扩展的表,所以在查询的时候比较麻烦!看下面代码

    #!/usr/bin/env python
#-*- coding:utf-8 -*-

from __future__ import unicode_literals
from django.db import models
from django.contrib.auth.models import User
#必须导入User模块
class UserProfile(models.Model):
    '''
    用户表
    '''
    #使用Django提供的用户表,直接继承就可以了.在原生的User表里扩展!(原生的User表里就有用户名和密码)
    #一定要使用OneToOne,如果是正常的ForeignKey的话就表示User中的记录可以对应UserProfile中的多条记录!
    #并且OneToOne的实现不是在SQL级别实现的而是在代码基本实现的!
    user = models.OneToOneField(User)
    #名字
    name = models.CharField(max_length=32)
    #属组
    groups = models.ManyToManyField("UserGroup")
    #朋友
    friends = models.ManyToManyField('self',related_name='my_friends')
    status = models.ForeignKey("UserStatus",related_name='user_status',blank=True,null=True)
    View Code

    CMDB表结构设计

    确认配置项，都要存什么设备：

服务器：
    -内存
    -CPU
    -Disk
    -网卡
    -raid
    -sn
    -型号
    -系统版本
    -状态

存储设备：
    -型号
    -Disk

网络设备：
    -网口数量
    -网卡信息（MAC地址等信息）
    -网卡速度
    -背板带宽
    -系统版本
    -管理IP

软件资产：
    -用途
    -版本

机房：
    -机房信息
    -机柜（最大U位，电源最大负载）
    -U位

设备有管理员
设备所属业务线：这里重要

业务线这里要写成有层级关系的业务线！
‘’‘
为什么呢？举例来说，百度贴吧的业务线，他下面有数据库的机器，有做缓存的、有做前端的。
一个业务线下面有好几个业务线！并且不能规定他有多少层！
这里很重要！类似多级评论~~~~~
’‘’
    View Code

     

     

    Restful API接口规范的设计与实现

    理解RESTful架构 :http://www.ruanyifeng.com/blog/2011/09/restful 

    RESTful API 设计指南 :http://www.ruanyifeng.com/blog/2014/05/restful_api.html　

    了解Restful API设计规范后如果能使用起来是最好了，平时需要注意的是URL中不能有动词。

    我们总结一下什么是RESTful架构：

    1. 每一个URI代表一种资源；
    2. 客户端和服务器之间，传递这种资源的某种表现层；
    3. 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

    最常见的一种设计错误，就是URI包含动词。因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。
    举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。
    如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：
    　　POST /accounts/1/transfer/500/to/2
    正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务：
    　　POST /transaction HTTP/1.1
    　　Host: 127.0.0.1
    　　from=1&to=2&amount=500.00
    另一个设计误区，就是在URI中加入版本号：
    　　http://www.example.com/app/1.0/foo
    　　http://www.example.com/app/1.1/foo
    　　http://www.example.com/app/2.0/foo
    因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分（参见Versioning REST Services）http://www.informit.com/articles/article.aspx?p=1566460：

    Django API框架

     重中之重：接口设计好

    • 可对内外灵活开放接口
    • 接口定义要标准化
    • 一定要提供排错依据 
    • 数据返回要标准
    • 要能增删改查
    • 所有异常要抓住为了排错
    • 接口安全要注意

    接口定义要标准化 (不能说随便起个名字 返回的数据的格式标准化)

    在别人调用你接口的时候的,要提示它因为什么原因导致出错了,比如他提交的数据不合法/或者服务器问题,为什么要做这个:防止给自己找麻烦,因为别人在调用你端口的时候刚开始很容易出错)

    理解API：

    API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

    简单理解API是我们提供的一个URL当用户按照指定的格式提交到URL中，我们在内部的views里执行操作，然后返回给用户状态or数据！

    那么有没有现成的提供了以上“重中之重的API设计里提到的那些API设计原则呢”？

    django-rest-framework    

    django-rest-framework 是一款比较不错的API模块，他为我们定义了很多功能和规范并且可以通过网页查看API

    Some reasons you might want to use REST framework:

    1、安装django-rest-framework

    pip install djangorestframework

    2、配置Django settings中注册APP

    INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'assets',
    'rest_framework',
]

    3、在Project中总URL重引入APP中的URL

    from django.conf.urls import url,include
from django.contrib import admin
from assets import rest_urls

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^api/', include(rest_urls)),
    url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
]

    4、配置Serializers序列化数据，这里配置展示什么数据并且被rest_views调用

    #!/usr/bin/env python
#-*- coding:utf-8 -*-

from django.contrib.auth.models import Group
from rest_framework import serializers
from assets.models import UserProfile
from assets import models

#定义前端展示什么,吧许菊进行序列化
class UserSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = UserProfile
        fields = ('url', 'name', 'email')

    5、和APP中的URL分开所以独立创建url&views

    #!/usr/bin/env python
#-*- coding:utf-8 -*-

from django.conf.urls import url, include
from rest_framework import routers
from assets import rest_views

router = routers.DefaultRouter()
#这里是url名称(看代码下面的图)
router.register(r'users', rest_views.UserViewSet)
router.register(r'groups', rest_views.GroupViewSet)
router.register(r'assets', rest_views.AssetViewSet)
router.register(r'servers', rest_views.ServerViewSet)

# Wire up our API using automatic URL routing.
# Additionally, we include login URLs for the browsable API.
urlpatterns = [
    #这里的route.urls这个把默认的路由分发改成类的形式了
    url(r'^', include(router.urls)),
    url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
]

    View

    #!/usr/bin/env python
#-*- coding:utf-8 -*-

from django.contrib.auth.models import Group
from rest_framework import viewsets

from assets.serializers import UserSerializer, GroupSerializer,AssetSerializer,ServerSerializer
from assets.models import UserProfile
from assets import models

class UserViewSet(viewsets.ModelViewSet):
    """
    API endpoint that allows users to be viewed or edited.
    """
    #这里是从获取数据命名必须为:queryset & serializer_class
    #但是这里获取所有数据的命令实际是否展示不是在这里设置的在serializers中设置
    queryset = UserProfile.objects.all()
    serializer_class = UserSerializer
    View Code

    6、测试

    #!/usr/bin/env python
#-*- coding:utf-8 -*-

from django.contrib.auth.models import Group
from rest_framework import serializers
from assets.models import UserProfile
from assets import models

#定义前端展示
class UserSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = UserProfile
        fields = ('url', 'name', 'email','password','is_admin')

    在什么情况适用API呢？

    外部和内部需要快速访问数据的时候适用，如果是自己的APP或者Project下不能适用，虽然可以使用但是相当于一个环了本来可以从自己内部快速取出来的（自己写的代码取）如果从APP取就慢很多了，相当于绕了一圈！当然API也可以自己写不用他这个框架，但是提示的内容和标准自己在写API的时候需要注意！

    API安全

    那么问题来了API，上面写的API随便谁都可以调用API进行操作，肯定这个是不安全的！那怎么办呢？

     

     

    原理：
    1、客户端与服务器都存放着用于验证的Token字段，值字段无论通过什么方法外部的黑客都是无法获取的。
    2、客户端吧本地的用户名+时间戳+Token的组合进行MD5加密生成一段新的md5-token
    3、客户端访问的时候携带：用户名、时间戳、生成的一段新的md5-token
    4、服务端收到请求后，先判断用户名、时间戳是否合法（时间戳和当前时间不能大于2分钟）
    5、用户名和时间戳都合法了，在去Redis中判断是否有当前用户的key判断是否在这2分钟有访问过，我这里设置Redis2分钟过期，即合法用户第一次访问后，把他的用户名加入到Redis中作为key：MD5作为vlaue存储。如果存在说明是在2分钟内访问的。拒绝
    6、以上都通过之后说明是合法用户和合法请求，然后在判断MD5值是否相等如果相同认证通过，执行相关Veiws然后并返回相关的状态或数据

    更多内容摘自Aelx金角大王的博客：http://www.cnblogs.com/alex3714/articles/5420433.html
  • 相关阅读:
    题解 CF171G 【Mysterious numbers
    题解 P1157 【组合的输出】
    题解 P3955 【图书管理员】
    题解 P2036 【Perket】
    题解 CF837A 【Text Volume】
    题解 CF791A 【Bear and Big Brother】
    题解 CF747A 【Display Size】
    题解 P1332 【血色先锋队】
    题解 P2660 【zzc 种田】
    题解 P4470 【[BJWC2018]售票】
  • 原文地址：https://www.cnblogs.com/longyuelu/p/8670498.html
Copyright © 2020-2023  润新知