CMDB: | |
I do not have names on specific commentors. These notes have been re-ordered to make a bit more sense. | |
We have dynamic environments, with information coming from systems and builds. | |
Systems need configuration from runtime data based on service discovery and build configuration (IP addresses, versions, etc). | |
CMDB use contexts: | |
On call users - The sysadmin who has been paged at 4 am needs to determine context for the page. | |
Deployment systems - To know where to deploy software, what version(s) to deploy, etc. | |
Maintenance - Downtimes, escalate, software versions, hardware info... | |
Management - Reports | |
Auditors - Licensing, security, change control, etc | |
Provisioning systems - To actually provision VMs/hardware | |
Configuration Management Software | |
CMDBs need a REST API | |
See PuppetDB for a good example of separate storage and API. | |
A CMDB should provide history. | |
Context can be things like system performance after rollouts, last n tickets, changelog for a rollout, etc | |
Limiting yourself to only current state is not good | |
We should be able to determine variability in systems | |
Not everyone needs access to context all the time. Too much context is noise, too little context ends up with human spending time in context discovery | |
A CMDB should be able to verify and validate data | |
This is needed to support audits, etc | |
Excel is a popular reporting system, but we do not want to use Excel as a frontend. | |
Autodiscovery is a useful feature, but daily or weekly discovery is not fast enough today. | |
Version control hooks are good. | |
Version control hooks which update/close tickets are fantastic. Well written commit messages assist in helping people determine context, act as documentation and assist in building a story about the system. | |
CMDB users are mainly other computers, rather than other people. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment