How do we handle all the user requests, problems reported and their solutions, keep track of it all and share with everyone?
As a first step, in these pages I will form a knowledge database. We do have the ticketing system, but given that the solution often lies somewhere different than the question from the user, a keyword search can yield too many results. Also, you may not even know what keyword to search for (particularly for newbies). We can rely on the good memory of our colleagues, but is not the ideal solution. Also grid is statically dynamic and dynamically static, so external manuals and documentation that may point in the right direction can be hard to come by.
The database will help us to identify the following:
-
What problems occur often and how do we resolve them?
-
Do we always offer a standard solution or it varies?
-
Which problems were never fully resolved?
-
What can we do about the unresolved problems?
-
What is obsolete and what is new?
-
How do we exchange knowledge?
-
How can we make the whole process of problem-solving and knowledge-exchange smoother?
We all went through a steep learning curve when we started learning about the grid. The better we understood and as our knowledge database expanded, it became easier to resolve problems. If all the information is logged, this process can be made smoother and efficient. Given the changing size of the group - additions as well as subtractions, a groogle (grid google) could come in handy (After coining the term found out what it actually means - http://www.urbandictionary.com/define.php?term=groogle) or a goud (google cloud, which means http://www.urbandictionary.com/define.php?term=goud). Just like we have a wiki for our users, a wiki for our internal usage could be very useful.
In these pages, I will segregate the reported problems (addressing the first 3 points above) and we take it from there. We can eventually resort to a tooling system (e.g., PUR, etc.) There are tools also being considered SURFsara wide, which as I undersatnd will be tested over the coming weeks (e.g., heat). To evaluate the usability of these, or any tool for that matter, we must first identify the type of problems we face and our workflow for resolving them.
If we don't see a solution from these tooling systems (ones under consideration at the moment) in the near future (I say in 2 months?) we shall explore other tools (suggestions welcome!). These 2 months will give me time to accumulate the information on a variety of problems and ensure all are categorized after taking inputs from the grid team.
The categories are as follows:
New projects --------------------- please check this one
Grid Certificate --------------------- please check this one
Grid Storage --------------------- please check this one
Miscellaneous unsolved problems
These are the categories derived from the grid-wiki. As we are starting the new year, I thought the beheerders could spend a few minutes after their shift ends and start logging the interesting tickets here. This way even they can go back to it in the future without having to look back in their emails or search in the ticketing system, and other colleagues with similar tickets can look up here. In the 'grid certificate' section I have logged my tickets as an example. I will request the entire team to also log the tickets from previous years which they think could be useful to complete our knowledge database. This is different from the grid-wiki, as it will target our team than our users. Of course this means a little extra work for all, but it will certainly help to improve the efficiency of our service and importantly build protocols - this is something that is not defined for all possible scenarios and not all our colleagues know about them.
While the tooling systems (PUR, HEAT) are under evaluation/development, having a data base with all this knowledge can be built. When these tools take over the knowledge management, this database will help us define what/how we would like these tools to do, and certainly define protocols.
We can either keep these pages here or move them to a closed location not accessible to others (Internal SURFsara pages perhaps?).
Please let me know what you think of this as a starting point. If you let me know soon, I can send the link around and discuss with our teams in the next group meeting.