Automation–System Center 2012 – Orchestrator Best Practice Series–Naming Conventions
As promised, I have a few blog posts coming on the topic of Best Practices as it relates to System Center 2012 – Orchestrator . Now, just like math problems, there is usually more than one path to come to the same solution. I call these Best Practices because I’ve found these practices work best for the environments I’ve implemented, supported, troubleshot, and optimized. Even better, I learned these from one of the gurus in the industry (Charles Joy). So, you could say I’m channeling Charles with a bit of my own "flair" 
. By definition, a best practice is one that works. If you have one already for these topics, go with it. If nothing else, there is always a benefit to seeing how someone else is doing it and potentially improving on your own custom practices!
Note: There is one more thing to be said before we start down the path of any best practice discussion and that is that you should start with a IT Process Automation mapping session. In other words, take what you have now that you are doing with disparate systems, manual and semi automated automation, scripts, etc. and put it out on paper or a Visio to understand what all the major moving parts are. Having a well thought out plan before diving into the best practices around Orchestrator is really one of the most important steps on this journey. This topic deserves its own post so look for it in coming posts within the Automation Track!
OK – Let’s Get on with the Naming Conventions
So Orchestrator let’s you have pretty much full reign when it comes to naming your folders, subfolders, Runbooks, Activities, etc. With this flexibility comes some added “tax” of ensuring you can follow flow through your Runbook execution and ensure you organizing your thoughts/code in some meaningful way. This should be a fun ride – but if you get these concepts, I think it will improve your overall experience of organizing within Orchestrator.
A Look at Hierarchy First
So let’s have a look at what I’m talking about at a high level first. This will frame up exactly what the next sections will dive into. You can see from the picture below, that these folders are sorted into a particular order to provide the “operator” an understanding of exactly what is going on when. As you follow through the rest of this post, you’ll hopefully see exactly what I mean. One thing for sure is this – for super complex Runbooks orchestrated like below, we (TED) or anyone else for that matter in my opinion, need to have an easy way to describe the flow. The example I’m using below is a Runbook for a future blog post but it shows nicely all the pieces we need to cover here.
Folder Naming
Sort of like a table of contents, you can get an outline of what is going on from the picture above. Just like a table of contents, you can go directly to the area that you want to get more information. It essentially frames up our “book” or Runbook more appropriately.
Top Level Folders
Let’s talk about top level folders first. These folders essential categorize the major sections of our Runbook design.
0.0 Main: This folder holds Maintenance Runbooks, Process, as well as Sub-Process level Runbooks. These are execution Runbooks that call sub-routines (explained next) via invoke activities. These can also be referred to as “orchestration” Runbooks.
1.0 Sub-Routines: This folder holds all Sub-Routine Runbooks that are called by Process or Sub-Process Runbooks. These can also be referred to as “operation” Runbooks because they process operational requests and return data back to the orchestration level Runbooks.
Note: Sub-Routine Runbooks will be technology specific where Process Runbooks should be targeted towards process specific orchestration. I’ll define the different types of Runbooks here shortly (don’t worry)
.
Secondary and Tertiary Folders
Secondary and tertiary folders are actually where the magic happens.
- 0.0.0 Maintenance: Process Runbooks that are executed only once (for setup) or for pre-flight checks at the beginning of the main Process Runbook (Recover Now), or for error handling purposes.
- 0.1.0 Process: This folder contains the main orchestration Process Runbook for execution of SharePoint Warm Recovery
- 0.2.0 Sub-Process: This folder contains the Process Runbooks related to Recovery Management and Virtual Machines. Still process focused and not specific to technology.
- 1.1.0 Recovery Management and 1.2.0 VM Management: These folders store the technology specific Sub-Routine Runbooks for performing the operational tasks for the Process Runbooks.
Folder and Runbook Numbering Convention
Next let’s get into the numbering scheme and why that is useful. See below, folders and Runbooks are numbered to show a relationship as well as order of processing.
Folder Numbering Convention
- 0.0 for “Main” Process Runbooks
- 1.0 for “Sub-Routine” Runbooks
- Within high level Runbook Folders, numbering increases by decimal according to the following format example. Deeper into the hierarchy, the folder numbering will increase to support an outline type format.
Confused yet?
– well hopefully this will help a bit.
Main
0.0, 0.0.0, 0.0.1, 0.0.2
0.0, 0.1.0, 0.1.1
0.0, 0.2.0, 0.2.1, 0.2.2
Sub-Routines
1.0, 1.1.0, 1.1.1, 1.1.2
1.0, 1.2.0, 1.2.1
Runbook Numbering Convention
- Each initial Runbook within a folder starts with a “0” sub numbering schema.
- Each additional Runbook in the same folder increments by one decimal value.
An example of this is below
Runbook folder name: 1.2.1 VM Start Process
Runbook numbering: 1.2.1.0, 1.2.1.1, 1.2.1.2, etc.
Folder and Runbook Naming Convention
Folder Naming Convention
- Process and Sub-Process Folder Naming: Folders are named according to function. These names are not specific in technology used such as DPM or VMM. Folders that exist within the Process folder section under Main take on a process type name such as “Recover Now” or “Start Virtual Machines”.
- Sub-Routine Folder Naming: Sub-Routine folders are named according to specific function and potentially naming the technology leveraged. Since Sub-Routine Runbooks are called by Process Runbooks, the actual technology is more specific when Sub-Routine functions are called. This is done to accommodate technology agnostic (if necessary) Runbooks while keeping the actual Process Runbooks in-tact.
An example of this is below
Recover Protected Resources calls Get DPM Info. If desired, Recover Protected Resources can be leveraged to accommodate an alternate recovery technology. If this were the case, an additional technology specific folder within Recovery Management would be created. The Runbooks in the Sub-Routines may be customized while the main Runbooks for processing would likely remain the same. Starting to make a bit more sense now?
Runbook Naming Convention
Runbook naming convention follows the same convention as folder shown above. This makes it very easy to understand and follow along as you move through the process of documenting, monitoring, and possibly troubleshooting your Runbooks and their execution.
Putting it All Together
As promised, let me now introduce the concepts of Runbook types. These concepts are worthy of a future post because if you get these concepts right, they will certainly define how well you design Runbooks in the future. I promise you that!
DON'T REPEAT YOURSELF (DRY) OPTIMIZATION
Runbooks should be architected and organized with DRY in mind. If you master this concept while building your Runbook dependencies and flow, you’ll have an easier time compartmentalizing and even sharing your Runbooks.
- Process and Sub-Process Runbooks: Process and Sub-Process Runbooks are a series of Invoke Runbook activities which call Sub-Routine Runbooks to execute data retrieval or reusable tasks and return data based on execution.
- Sub-Routine Runbooks: These are Runbooks that are called by Process and Sub-Process Runbooks and traditionally do not contain Invoke activities. Sub-Routine Runbooks are comprised of linked activities to execute tasks on behalf of a Process or Sub-Process Runbook. An example of a Sub-Routine Runbook is "Recover Virtual Machine"
That is enough for now! Future posts will cover other best practices for System Center 2012 – Orchestrator Runbook design and optimization. Stay tuned!
Until next time, Happy Automating!
Comments
- Anonymous
January 29, 2014
Voici une suite d’articles concernant les bonnes pratiques pour System Center Orchestrator 2012 - Anonymous
August 14, 2014
大家好！
到目前为止，尤其是如果大家阅读本文，那么很可能已经阅读过以下几篇博客文章：
自动化 – Service Management Automation 简介
自动化 - Anonymous
August 14, 2014
大家好！
到目前为止，尤其是如果大家阅读本文，那么很可能已经阅读过以下几篇博客文章：
自动化 – Service Management Automation 简介
自动化