Differences

This shows you the differences between two versions of the page.

--- onboarding:ticketer:ticketer_-_preventative_maintenance_introduction [2017/01/23 12:31] – created srenshaw
+++ onboarding:ticketer:ticketer_-_preventative_maintenance_introduction [2021/06/25 10:09] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== Ticketer - Preventative Maintenance Introduction ======
+Author: Sophie Renshaw
+=====What is Preventative Maintenance?=====
+Preventative Maintenance is a process that both of our major customers carry out. The majority of the tickets that are created in the Ticketer are reactive i.e. they are created to respond to an event, usually created by an alarm in the system. But there are a number of tickets that are created to be proactive. These ticket are Preventative Maintenance (PM) tickets. The aim of Preventative Maintenance is to carry out work on the network element as the same time each year, to fix any issues before they may become a big problem.
+PM Tickets are created automatically by the Ticketer once a certain date has been reached. This is usually the first day of every quarter but can be configured to create at other times. Our customers define the schedule for when they want certain tickets to create and the Ticketer creates tickets according to this. The schedule allows the customer to decide when network elements will ticket for PM and to avoid every network element in the system creating a ticket on the same date.
+Once the ticket is created it is assigned to a field technician, usually based on network element location but can also be assigned to specific contractors in the area etc. Once the field technician is assigned to the ticket they will be able to view this ticket in the Mobile Ticketer application.
+The field tech will visit the network element(s) and carry out some checks based on the checklist that is attached to the ticket. They also have the option to upload photos to the ticket. Once the checks have been completed the field technician will move the ticket to the appropriate closed state, based on whether an issues has been identified or not. The field technician will not fix the issue as part of the PM process, another ticket is usually manually created for this. When the ticket is closed, along with the PM ticket policy, defines when a PM ticket will next create. The process is repeated once the next PM date rolls around.
+----
+====How the PM Process works====
+===Some Important Database Information===
+There are 4 database tables that we're interested in when it comes to the PM process:
+  * ticketer.ticket
+  * ticketer.maintenance
+  * ticketer.external_element
+  * snmp_manager.network_element
+The combination of the maintenance and external_element tables allow us to connect the ticket table to the network element tables, along with holding information about each network element's maintenance.
+ticketer.ticket joins to ticketer.maintenance using the maintenance.current_open_ticket_id = ticket.id **OR** maintenance.id = ticket.maintenance_id
+ticketer.maintenance joins to ticketer.external_element using the maintenance.external_element_id = external_element.id
+ticketer.external_element joins to snmp_manager.network_element using the external_element.remote_id = snmp_manager.id
+Some key database fields:
+  * ticket.id - ID of the PM Ticket
+  * ticket.maintenance_id - ID of the tickets maintenance entry
+  * maintenance.id - maintenance ID
+  * maintenance.active - is the maintenance currently active?
+  * maintenance.current_open_ticket_id - the ID of the ticket that is currently open for this maintenance
+  * maintenance.expired - is the maintenance expired?
+  * maintenance.external_element_id - the ID of the external element linked to this maintenance
+  * maintenance.next_ticket_date - the date that the next PM ticket will create
+  * maintenance.ticket_policy_id - the policy that this PM maintenance uses to define ticket creation (quarterly, yearly, etc.)
+  * externaL_element.id - ID of the external element
+  * external_element.active - is the external element active?
+  * external_element.remote_id - the ID of the network element that the external element is linked to
+  * external_element.acceptance_record_id - the ID of the acceptance ticket (See section on Acceptance)
+  * network_element.id - the ID of the network element to be PM'd
+----
+===From Network Element to PM Ticket===
+There are a number of quartz jobs that are used to manage the PM process. These quartz jobs makes the entire PM process automatic, with the only manual intervention being the changing of a PM schedule. Before a network element begins the PM process it must complete the Acceptance Process.
+----
+===Customer Workflows===
+**ExteNet**
+ExteNet use 2 workflows to manage their PM process - Preventative Maintenance and Manual Preventative Maintenance.
+Both workflows have the same states and connections but the forms and groovlets differ.
+{{:onboarding:ticketer:screen_shot_2017-04-14_at_10.31.39.png?700|}}
+See ExteNet PM Process Changes section for more info
+----
+**PM Process**
+Once the acceptance ticket has been moved into Inspection Complete the next_ticket_date will be set to be the current quarter, on year from now. e.g ticket closed on the 23rd January 2017, the next_ticket_date will be set to 2018-01-01 00:00. The 1st January, 1st April, 1st July and 1st October are the first day of each of the quarters, so they will almost always be set to be that date.
+Once the next_ticket_date rolls around and the MaintenanceManagerJob has ran the Preventative Maintenance ticket will be created and assigned to the relevant field technician. The field tech will carry out the necessary checks and move the ticket into the relevant closed state. This usually happens within the quarter that the ticket is created in, setting the next_ticket_date as the current quarter, one year from when the ticket was closed. If a ticket is not closed within the quarter it is created it will be moved to an Overdue status, the next time the MaintenanceManagerJob runs. When this ticket is eventually close it will now have a next_ticket_date of the current quater, one year from the closed date. So if the ticket was opened in Q1 2017 but didn't close until Q2 2017 then it's next ticket date will be 2018-04-01 00:00.
+===Setting Preventative Maintenance to be expired/inactive for a Network Element===
+To stop a network element from creating PM tickets both the maintenance active and expired fields and the external element active field need to be marked as false.
+----
+====ExteNet PM Process Changes====
+For ExteNet the process is slightly different. The same basic functionality is there including maintenances, external elements, next ticket dates etc.
+As seen in the above workflow a ticket is created in the PM Required state. A PM Scheduled form is added here which requires the Field Tech to log in on the Mobile Ticketer to view and schedule the Maintenance. Initially the Field Tech will only see the Hub Tickets that are assigned to him. Once he has completed the form and moved the ticket to the PM Scheduled state the Remote tickets will be assigned to him and will appear in the Mobile ticketer for him to see, with their PM scheduled form populated with the same information that is in the Hub PM scheduled form. At the PM Scheduled state, depending on the network element system type a checklist will be added to the form, which the field tech will complete. They will then move the ticket to the appropriate closed state. The usual PM Process will then take place, setting the next_ticket_date to be the current quarter, next year.
+The Manual PM Workflow works in a similar way but as the ticket is manually created there will be no maintenance or external element entry for it. The PM Scheduled form contains fields to allow the NOC user to populate the ticket with network element information. This information is required to allow for the correct emails to be sent out as the ticket moves through it's states.
+----
+====ExteNet PM add elements to External Element & Maintenance tables====
+Take a backup of external_element and maintenance tables before starting. ExteNet usually supply support with a list of new elements that PM tickets are required for.
+Construct a mysql query that returns these elements; queries usually use the network_identifier column. In the Ticketer application go to admin - External Tables controller. The two entries we are interested in are Hub Maintenance & Remote Maintenance; Hub Maintenance is for ne_type Controller and Remote Maintenance is for ne_type Node.
+Run the Elements List Query for both these entries in workbench.Take note of the number of rows returned. For Controllers edit the Hub Maintenance Elements List Query to return the additional Controllers; for Nodes repeat the process with the Remote Maintenance Elements List Query. The additional elements should now be returned by running the Hub Maintenance and Remote Maintenance queries.
+If the correct elements are been returned edit the Hub Maintenance and or Remote Maintenance Elements List Query to include the updated queries. Take note of the number of external_element & maintenance entries. To populate the new entries run the Full Table Update for Hub Maintenance and Remote Maintenance if they have been edited; tail the logs when running the Full Table Update. Additional elements should now be added to the external_element and maintenance tables.
+----
+=====Assessment=====
+  - Familiarise yourself with the different database tables & fields, workflows and forms that are part of the PM process for all customers.
+  - On Errigal QA locate a PM ticket that is currently in PM Required. Make note of this tickets next_ticket_date. Move this ticket through the states, filling in the relevant forms, until the ticket reaches a closed state. Confirm that the next_ticket_date has been set to be the current quarter of the next year.
+  - On Errigal QA edit the next ticket date of an active maintenance to be today's date. Watch the logs on both handlers to see the new ticket being created. You can also start the quartz job to create the ticket.
+  - On Errigal QA delete a maintenance entry for an external_element. Wait for the quartz job to run and watch the logs on both handlers to see the maintenance being created. You will need to set the next_ticket_date to see the ticket create. Do this using the PM export.
+  - On Errigal QA delete an external_element entry for a network_element. Start the quartz job (hint: this one runs every 2 days) and watch the logs on both handlers to see the external element create. The maintenance should also create. You will need to set the next_ticket_date to see the ticket create. Do this using the PM export.
+  - On Errigal QA co-locate some tickets. Make some changes to the ticket and select to apply changes to the group. Confirm that the changes have been made to all tickets in the group. Make some changes to just a single ticket. Confirm that the ticket has been removed from the co-located group.
+  - On Errigal QA close all tickets that are part of a co-located group. Set the next_ticket_date to be today for all elements in the co-located group. Allow the quartz job to run and confirm that it created the tickets and added them to the same co-located group, including the ticket for the element that was removed from the group in the last step. Add and remove more elements to this group and ensure the changes that you make apply correctly.
+[[https://qalb1.err/Ticketer]]

Sidebar

Internal Errigal Collaboration Wiki

Differences

Sidebar

Internal Errigal Collaboration Wiki

User Tools

Site Tools

Differences

Page Tools