Alt+Ctrl+Start

This post is based around IT operations and engineering, and supporting systems and applications.

This isn’t targetting specific IT users but is a generic but useful post on those wanting to improve, learn and further develop their IT support skills. Even non operations and engineering staff can grasp some extra perspective on to better support the product or service

• Over the years, there has been a multitude of systems and programs developed
  • These systems have different flows, connections, designs which haven’t been documented over the years (this is a fact based on experience)
  • This makes it harder for you as an IT professional to understand these systems and applications from the word go
• Knowing the basics of systems and applications is a must, i.e., OSI stack
• Picture the following
  • You land a new job supporting a complex multi-tiered system or application
  • There are several teams (most, if not, all siloed) also supporting these systems
    • Some of these teams are friendly and some others…. well need a bit more warming up to 🙂
    • Some of these teams have deep knowledge and other teams don’t
  • Once you’ve been given the introduction and onboarding (if you get onboarded smoothly. This will be a topic for another day) your team lead or manager will start blabbing on what needs to be done to keep the system alive
  • Existing IT professionals just go straight to terms, words you’ve never heard of and by the end of the day you’ve wondered what you’ve learned and if you’ll ever get to understand supporting / learning these systems
    • This feeling will probably go for a few weeks until you reach a point where you feel comfortable with what you’re supporting….
      • That’s until you run into the one-off scenarios that only occur once or twice a year
      • Also wait until these one-off scenarios occur only to find out some of your team has left that knew about these one-off issues
• Do you get what I’m explaining?
  • The above is just one example of many on what happens in an IT workforce
  • However, let me prepare you on what you need to know from the word go, so you master your product or service in a much shorter time frame
• Read my techniques below on how to begin learning systems
  • I cover all aspects both technical and user perspectives

Technical

• Is there any existing documentation
  • Ask the manager/team lead if there is any existing documentation. Expect there will be none or it might be outdated
• Work your way from the front
  • Picture the system like a house; when you enter the house, you go through the front door and then you make your way through the house
  • A system is no different; find out the front end of the system, know how to access the front and from there you’ll be presented with different buttons and functions
    • E.g. login graphical screen/interface that has buttons and functions or command line interface
• Backtrack to the front from the backend
  • Ok, now you’ve managed to learn to go through the system from the front; now validate if the system is able to go backwards
    • What I mean by this: does the system also send some reverse (i.e. response API call) back to the front?
• What access do I need?
  • Do you just need the bare bones basic login access or will secondary access to other systems be needed?
    • If your team has access to these secondary accesses and they are not present, will it help if you can have this access as well, or is it an acceptable risk that you don’t have this secondary access?
• Where is it hosted?
  • Systems and applications all have to live somewhere (aka hosted)
    • When I refer to where systems are hosted, it indicates the infrastructure of the system
  • Is the system all cloud-based, on-premise (physical on-site servers), or hybrid?
    • Did you need access to these services?
      • Maybe read-only access might be beneficial for you to learn this side of the system
  • Side note – Are you interested in cloud computing? If so, knowing some of the services in the cloud that host systems will benefit your knowledge
• OSI layer knowledge
  • Just like you learned in college/university, every system works on the OSI layer
  • You will most likely be supporting the application layer
  • However, when functions get executed, the data will flow through the other layers
  • Consider the following:
    • What is the form or structure of data?
      • Is the data fixed or dynamic?
        • What happens if dynamic data is entered into a fixed structure?
          • Most likely something will break and/or the data will not be delivered
    • How do I know when the data reaches the destination from the source?
    • What happens when the network is down?
• Top 5 functions and critical timings
  • The system performs certain functions to action; get the top 5 functions (or more if needed)
  • Be sure to document these important functions and timings for yourself
    • Create a run sheet confirming the success and failure of these functions executing
    • If these functions are minuscule, perhaps documenting this might not be necessary
    • E.g. function 1 – email system for Sr. product stakeholders notifying of critical orders not fulfilled, function 2 – online payment system logging of missed orders sent at 2 PM, function 3 – inbound file containing a list of accounts and payments to be stored and processed at 9 AM, etc.
• Top 5 issues or gaps with the system
  • Is there anyone developing or improving the system?
  • Can this system both move forwards and backwards?
    • I.e., if 1/2 a data file gets sent to your system to process, can it receive the other 1/2 later and reprocess that data file?
      • Or will the system already recognize the first 1/2 file was already sent and the other 1/2 can no longer be processed?
        • What would happen in this situation?
• Is this system off the shelf or custom?
  • If this system is off the shelf, does it have vendor support or has the vendor closed and the system is end of life?
    • If the system is off the shelf, maybe research and Google some things on the vendor
  • If the system is custom, you’ll need to gather some information to build your knowledge
    • Refer to the ‘user’ section later in this post to build a personal list of requirements to aid you in your system knowledge
    • Are there any flow diagrams, charts, or graphs showing the different hops?
• What happens when something breaks?
  • Define and confirm who looks after what for each part of the system
  • The system is probably going to be vast, and each system will have other teams looking after their parts
• Does the company/business follow ITIL procedures?
  • Information Technology Infrastructure Library – industry standard for looking after all aspects in the IT space
  • Is it formal, informal, or non-existent?
    • E.g. when the system is on fire (aka not working), do we start calling everyone in the phone book or is there a calm arranged process to follow?
      • If there is a process, what is it? Can anyone show me?

User

• Who
  • Else knows about these systems
  • I need to create a list / table of IT users that have knowledge
    • I also need to create a list of IT users who know nothing and stay in the comfort lane
      • Trust me this list will be handy later on. Build and form the relationships that are most important first
      • Just don’t publish it publicly 🙂
    • Who is accountable for what parts of the system?
      • I.e. who gets the blame / falls onto the sword when something doesn’t work
• Where
  • Are these other IT users based?
  • Are they remote, on-site, where do they sit?
    • Can I access them verbally, remotely, through text, (telepathically?)
• What
  • Do others know?
  • Who has been here the longest?
    • Will they have the deep knowledge I need?
      • How do I get it out of their head?
      • What smart and structured questions can I ask?
    • Who has been here a while but doesn’t know anything?
      • (Refer to ‘who’ section)
• Why
  • Do these systems work at certain times?
    • Are there SLA’s (Service Level Agreements) agreed with other IT users and/or stakeholders?
      • What happens when we don’t meet those SLA’s?
        • Is this documented somewhere?
• When
  • Are the other IT users supporting these systems available?
  • Are these systems available (along with the other IT users)?
    • I.e. System A is working between 5 am – 6 am, System B is working between 9 am – 11 am, both System A and B are not available during 10 pm – 12 am, so Sys admins can do patching and updating etc.
      • Note to self – Sys admins available between 10 pm – 12 am…. can I see what they do, so I can learn this side of the system?
• How
  • Do I engage the other IT users?
  • Do I support other team members?
    • What are their expectations from me (despite me being new)?
  • Do I demonstrate my skills, go above and beyond later in my role?
    • (Refer to my 10% post)

Other (aka gotchas)

• Is anyone planning to leave when I start?
  • Do I need to obtain any further information before these other IT users leave
• Is there any gaps (probably) still in my knowledge base
  • Are there things I’m not being told?
  • Is this a gut feel or people around me are maybe hiding something from me?

Summary:

• There was a bit to cover on this post
• Re-read and review this post and reflect on the parts you are not familiar with
  • Be sure to write down what you are unsure about
• Review the OSI stack, every system is based on this principle
• Question every hop, step and function of the system you are supporting
• Remember to document your learnings along the way