Daily Activities

1. Server Monitoring
2. Application Heath checkup
3. Ticket Monitoring
4. Business Queries
5. Adhoc Request
 Daily Activities

1. Server Monitoring
2. Application Heath checkup
3. Ticket Monitoring
4. Business Queries
5. Adhoc Request
 Tickets/Incidents

1. Register the ticket

2. Choose appropriate severity
3. Ticket assignment
4. Follow up
5. Closure
 SLA

1. Critical
2. High
3. Medium
4. Low
 Issue Analysis/Fix Process
1. Understand the issue
2. Check it in log files
3. Action on the ticket
4. Update the stake holders
5. Fix/Promotion
6. Closure
 Deployment Process
1. Files from development team
2. Deploy in UAT/Pre Prod Env
3. Testing
4. Approvals
5. Change Request
6. Deploying in Prod Env
 Monitoring :
• Different monitors are created for application servers,
database servers and for different services depends on
the importance of the module.
• If any monitor is in red color that particular service is
down at that moment.
• For critical application we have to make sure that all
the monitors are in green all the time especially
application/database server’s CPU utilization monitors.
• If these monitors are in red, application may go down
in few seconds.
 Application Health Checkup

By doing regular checking of outdated(initial used)

queries used in the application(if the application is
running for several years) and try to optimize and
implement the new changes will help application to be
more stable and strong.
 Ticket monitoring
• Regular checking of application queues to find any
tickets and get it assigned to our id.
 Business Queries :

• Business related queries/data change requests will

be receiving through tickets only.

• After getting approvals only will change the data as

per the request and close it once it is done.
 Adhoc Request:
This type of request(business support /production
support) can also be start working on after getting
proper approvals only. Depends on the priority we will
take an action accordingly.
 TICKETS/INCIDENTS
• There are different types of tickets :
• Incident tickets(critical, high, medium & low): If there
is any particular functionality of a module is
failing(breaking) then we create an incident ticket
depends on the priority. If it is a critical will try to
resolve in 15 mints if not possible we will check for
alternate solution as temporary fix and close the
ticket.
• Problem tickets(critical, high, medium & low): For all
incident report ticket there will be a corresponding
problem ticket to fix permanently.
• General tickets (medium & low) : It can be anything
like extracting report, enquiry etc…
It will be assigned based on the application
queues. Some tickets we may need to follow up with
other teams(server/DB) based on the criteria. Once
issue is resolved we can close the ticket.
 SLA

• Critical( should be resolved/closed in 15 mints)

• High(24 hrs)
• Medium(15days)
• Low( 2 months)
 Issue Analysis /Fix Process:
• Understand the issue based on the description
mentioned in the ticket.
• Try to analyze the issue by capturing the logs and
data captured in the corresponding tables by the
module.
• After finding the cause of the issue try to fix with
corresponding teams
• (WAS/DB/AD – if it is code fix).
 The Problem Management Process
• 1. Detect
the problem.
– A problem is raised either through escalation from the
service desk, or through proactive evaluation of incident
patterns and alerts from event management or continual
service improvement processes. Signs of a problem include
incidents that occur across the organization with similar
conditions, incidents that repeat despite otherwise
successful troubleshooting, and incidents that are
unresolvable at the service desk
• 2. Log the problem.
– Problems are logged in a problem record. A problem
record is a compilation of every problem in an
organization. This can be accomplished via a ticketing
system that allows for problem ticket types. Pertinent
problem data, such as the time and date of occurrence,
the related incident(s), the symptoms, previous
troubleshooting steps, and the problem category all help
the problem management team research the root cause
• 3. Categorize the problem.
– Problem categorization should match incident
categorization. Incident [and problem] categorization
involves assigning a main and secondary category to the
issue.

• 4. Prioritize the problem.

– A problem’s priority is determined by its impact on users
and on the business and its urgency. Urgency is how
quickly the organization requires a resolution to the
problem. The impact is a measure of the extent of
potential damage the problem can cause the organization.
Prioritizing the problem allows an organization to utilize
investigative resources most effectively. It also allows
organizations to mitigate damage to the service level
agreement (SLA) by reallocating resources as soon as the
issue is known.
• 5. The fifth step is a two-part process, which
involves investigating and diagnosing the problem.
– High-priority issues should always be addressed first, as
their impact on services is the greatest. Correct
categorization helps here, since identifying trends is easier
when problem categories correlate to incident categories.
Diagnosis usually involves analyzing the incidents that lead
to the problem report as well as further testing that may
not be possible at the service desk level, such as advanced
log analysis.
• 6. Identify a workaround for the problem.
– A workaround should always be indicated, because
problems are not resolved at the incident level. A
workaround enables the service desk to restore services to
users while the problem is being resolved. A problem can
take anywhere from an hour to months to resolve,
therefore a workaround is vital. A problem is considered
open until resolved, so a workaround should only be
considered a temporary measure.
• 7. Raise a known error record.
– Once the workaround has been identified, it should be
communicated to staff within the organization as a known
error. It’s good practice to record a known error in both an
incident knowledge base and known error database
(KEDB).

• 8. Resolve the problem.

– Problems should be resolved whenever possible.
Resolution resolves the underlying cause of a set of
incidents and prevents those incidents from recurring.
• 9. Close the problem.
– This step should only occur after the problem has been
raised, categorized, prioritized, identified, diagnosed, and
resolved.

• 10. Review the problem

– It is an organizational activity that prevents future
problems. During the review, the problem management
team evaluates the problem documentation and identifies
what happened and why. Lessons learned, such as process
bottlenecks, what went wrong, and what helped should be
discussed. This is where having a complete problem log
will help
 Incident Management
An incident as an unplanned interruption to or quality
reduction of an IT service.
The service level agreements (SLA) define the agreed-
upon service level between the provider and the
customer.
Incident prioritization is important for SLA response
adherence. An incident’s priority is determined by its
impact on users and on the business and its urgency.
Urgency is how quickly a resolution is required; impact
is the measure of the extent of potential damage the
incident may cause.
• Low-priority incidents are those that do not interrupt
users or the business and can be worked around.
Services to users and customers can be maintained.

• Medium-priority incidents affect a few staff and

interrupt work to some degree. Customers may be
slightly affected or inconvenienced.

• High-priority incidents affect a large number of users

or customers, interrupt business, and affect service
delivery. These incidents almost always have a
financial impact.
• Once identified, categorized, prioritized, and logged,
the service desk can handle and resolve the incident.
Incident resolution involves five steps:

• Initial diagnosis: This occurs when the user describes

his or her problem and answers troubleshooting
questions.

• Incident escalation: This happens when an incident

requires advanced support, such as sending an on-
site technician or assistance from certified support
staff. As mentioned previously, most incidents should
be resolved by the first tier support staff and should
not make it to the escalation step.
• Investigation and diagnosis: These processes take place
during troubleshooting when the initial incident
hypothesis is confirmed as being correct. Once the
incident is diagnosed, staff can apply a solution, such
as changing software settings, applying a software
patch, or ordering new hardware.

• Resolution and recovery: This is when the service desk

confirms that the user’s service has been restored to
the required SLA level.

• Incident closure: At this point, the incident is

considered closed and the incident process ends.
 Incident Status
• The new status indicates that the service desk has
received the incident but has not assigned it to an
agent.
The assigned status means that an incident has been
assigned to an individual service desk agent.

• The in-progress status indicates that an incident has

been assigned to an agent but has not been resolved.
The agent is actively working with the user to
diagnose and resolve the incident.
• The on-hold status indicates that the incident requires
some information or response from the user or from a
third party. The incident is placed “on hold” so that SLA
response deadlines are not exceeded while waiting for
a response from the user or vendor.

• The resolved status means that the service desk has

confirmed that the incident is resolved and that the
user’s service has restored to the SLA levels.

• The closed status indicates that the incident is resolved

and that no further actions can be taken.