CMDB Reflection 3

CMDB Model Design 1

Http://blog.vsharing.com/xqscool/A1274634.html

The problem of classification has more sentiment. Prior to writing the new version of the CMDB model, the blades, x86 servers, small machines and other unified server, through the architecture and chassis (blades, racks, vertical, as if these three kinds of) differentiated. Because of the use of SD, and to my period when the field is not much, in order to facilitate statistics and display, just out of the way--but then feel very good ha, finally eminence, but also helpless choice.

If the classification can be customized on the storage and presentation, and there is enough space, it is true that the classification should not be stingy, as the broken son said. It is curious how the data structure of the CMDB used by the broken subsidiaries is designed, and I have been having problems in this area for a long time, always worrying that too much flexibility will affect the performance, after all, the use of tens of thousands of records of the correlation and lookup will be very cost database performance.   classification is the simplest, unlimited classification, up to add a picture and description, the other is nothing. The design of the   attribute set is the same as what the breaker thinks, because if you develop an overly flexible feature like HP SD, it can cause system configuration to be abnormally responsible, and it is easy to affect the system functionality due to some trivial problems. Each property in a property set may have its own features, such as a set of properties for maintenance information, a start date, an end date, a renewal history, a renewal file, and so on, and you can set a reminder of how many days before the end date. Each class of attributes also needs to have corresponding explanatory text (not necessarily just text) to instruct the user to fill in. The relationship between  ci and CI is also my biggest problem, n multi-class CI relations are called as "installation", and because the user early participation is not enough, so we all expect to be able to define and limit after the system development, such as when the server associated with a software, there will only be automatically select a relationship, That is the installation, when the server associated with a network device, will only automatically select a relationship, that is, the connection and so on, of course, the above example is relatively simple. The above-mentioned relationships are given in categories and are related to the description. Relationships require the class-class relationship matrix to be sorted out in advance so that an optional relationship can be determined directly from the current class and Target class (though there should be only one relationship between classes and classes). Connection Description This is a good understanding, or at least the number of physical connections can be filled in AH ~ Let me more headache is the "availability of" this relationship, for example, in the availability calculation, the impact may be one-way or two-way, and different directions also have a percentage. Different relationships such as "availability delivery", "Connect", "call", and so on, seem to be implemented by different modules. If a physical connection relationship is called a "hard" relationship, then the call relationship between software is a "soft" relationship, and the "hard" relationship will definitely have an impact on the "soft" relationship. Think of here, and think of a problem, connection, call in the monitoring point of view will also have an impact, halo. The exhaustion of the relationship in the company is more difficult to engage in, headache.   It's interesting to feel the action when I'm in the CMDB model of the child. Because in the architecture diagram that I'm thinking about, the job is controlled by a separate system and associated with the CMDB. After two days of thinking, if you can define actions in the CMDB, it does help standardize the service, but where are the actions recorded? In accordance with the meaning of the text, it should be a series of operations？ It is my understanding that defining an action in the CMDB is just to keep an interface with other systems, and to correlate actions with other systems ' jobs in a timely manner, so that standardization or automation can be achieved. Perhaps automation is a matter of late, so how do these early actions relate to process, work-phase? How to accurately record time, these are the questions. Standardized action if you want to be equipped with the appropriate information, then you need to consider different brands, different models of the problem, of course, through the database to match the appropriate technology is not difficult.   See the idea that the service of the broken son and the CMDB combine, indeed gave me a lot of revelation. Some of the questions that have not been figured out have been felt somewhat clear. Part of the   service object, which was previously used as a CI management in the company, and then each system also has a molecular system and components, each system and other systems will be composed of system groups ... Of course, the previous one was due to the convenience of computing usability, the latter being purely egg-sore and pleasing to the client. Can you imagine what it feels like to have a system group in the hands of a man? So the industry said to annoy SA careful to kill skill. Service objects should be divided into service management, the CMDB do not engage in any service, look at the headache. If so, then like the PC service, the service object should directly contain all the customer's pc--I estimate that the management will have a headache, because they think this is not our management, customers should be happy, because they think this is our tube. This question has yet to be considered.   How to pinpoint the impact of events is one of the most tangled issues for leaders. The concept of service subject needs to be determined according to each service, and our General signing Framework agreement, Business system operation and maintenance services are generally a brain called over. After the concept of the service principal is added, the signing agreement requires the user to cooperate to determine who the service subject is, and when the information is clear, the impact surface is basically determined. Oh, we have a separate administration here, so the service principal can use the agency information directly--but this institution is changing all the day, I look at it. ......  Service System I think about it first. The service may have a service supervisor here. But the role mappings specified in the system are not fixed, which leads to the fact that an employee needs to be assigned a number of roles, even one-time roles. If you can automatically map ... I think a lot. The definition of the   service level needs to be consistent with what the customer has signed, so that alarms can be generated automatically when approached or below. and the time limit requirements of various types of work orders can also be taken from the service level, the countdown to a more strong sense of urgency, the system involved in the personnel will also be from the overall understanding of their own responsibilities.   Finally some tangled, the idea of broken son really good, but eventually developed such a complex system, I am really worried about whether someone in the department will use the configuration? There are too many things to know.
The last thing to say: I am, you have studied too deeply.