Exhibit_3c_TFITS_Performance_Measurement_Plan.pdf

PERFORMANCE Measurement PLAN

FOR THE

Total Force Information Technology Systems

(TFITS)

Version 1.0

December 12, 2013 initiator:pam.mcconnell@qinetiq-na.com;wfState:distributed;wfType:email;workflowId:96e99ec93946b84d92bde64486f5e138

SIGNATURE PAGE

CONCURRENCE

X

Mr. Robert Lovejoy Assistant Product Manager – APdM-E

PMM110 IS&I

Marine Corps Systems Command

APPROVED BY

Mr. William Sandlin Product Manager (PdM) PMM110 IS&I, APdM TFITS Marine Corps Systems Command

TFITS Performance Measurement Plan

Version 1.0

RECORD OF CHANGE

Version # Date Figure, Table, or

Paragraph #

*A, M, D Title of Brief Description

Change Request #

1.0 Dec 12, *A-Added, M-Modified, D-Deleted

Total Force IT Systems: Performance Measurement Plan

1.0 Identification

1.1 GENERAL SCOPE

The guidelines contained within this document define Information Technology (IT) and

Systems Engineering metrics standards set by the Total Force Information Technology

Systems (TFITS) Product Management Office (PdMO) for its portfolio of projects and their supported IT system. This guide provides all managed projects with a framework for reporting a set of core and specialized metrics to baseline system element performance and report a standardized set of Key Performance Indicators (KPIs) to stakeholders.

1.2 Purpose

Performance measurement is a critical function supporting the system/software acquisition lifecycle and product management functions. To ensure a proper user experience, metrics outlined in this guide will be collected by the PdMO using the Metrics Report Form in Appendix A or future Government supplied COTS/GOTS tool.

These metrics help the maturation process for each system, project officer, and supporting contract team to analyze and quantify normal behavior of a system. As new changes are introduced to each environment, having a properly defined and established baseline will help all stakeholders understand the impact of each change, and help the evaluation process.

TFITS Performance Measurement is tracked and monitored by Tier II and Tier III projects and reported to Tier I IPT leads for analysis. All processes and best practices for systems engineering functions are properly identified in section 1.3, reference documents; all TFITS performance measurement activities will remain compliant with these plans, to include proper configuration management and test and evaluation strategies for data collection and testing standards.

1.3 Reference Documents

1. TFITS Systems Engineering Plan (SEP)

2. TFITS Requirements Management Plan (RMP)

3. TFITS Test and Evaluation Plan

4. TFITS Configuration Management Plan (CMP)

2.0 Performance Metric Definition

All performance metrics are provided a “Metric Priority”. This category of metric defines the Product Office’s priority for establishing this as a baseline metric within each project.

Priority 1: Metric is essential. It provides greater value to analysts when determining overall health and maturity of an IT system.

Priority 2: Metric is vital, but may incur unplanned costs or additional resources that require proper planning and/or funding allocation.

Priority 3: Metric provides value, however additional costs are likely and must be planned and prioritized behind level 1 & 2 metrics.

2.1 Application Specific Metrics

Application specific metrics are those pertinent to one, or a small subset of TFITS systems. These metrics will focus specifically on the performance elements of that environment that directly impact user experience and critical mission functions. For this reason, all application specific metrics are considered priority 1 and essential for measuring overall system quality. (Example) metrics may include: 1) ODI-RMS web page load times for Temploan/Charge out Reports, 2) TFSMS TOECR processing time, or 3) time to run an Officer Longevity Report for TFDW.

Due to the exhaustive list of TFITS applications and range of services provided and use cases they fulfill, PdMO TFITS engineers will work with each project to define application specific metrics and document in a fashion similar to those presented in this guide.

Sample metrics common for system/application performance monitoring may include:

ID # Performance Metric

Reporting Frequency

Reporting Details

2.1.1 Search Query

Execution Time

Monthly/Per system Change

List

- Identify each critical search query performed on the system

- Identify baseline query execution time

- Identify monthly or recent GAT execution test results

- Identify performance delta per systems engineer guidance

2.1.2 Key Web Page

Load Time

Monthly/Per System Change

List

- Identify each critical web page

- Identify baseline web page load time

- Identify monthly or recent GAT execution test results

- Identify performance delta per systems engineer guidance

2.1.3 Workflow

Execution Times Monthly/Per System

List

- Identify each critical workflow

Change execution performed on the system

- Identify baseline workflow execution time

- Identify monthly or recent GAT execution test results

- Identify performance delta per systems engineer guidance

2.1.4 System Interface

Errors (impacting web/report/query load times)

Monthly/Per System Change

List

- Identify all system interfaces connecting to 3rd party systems

(IE. JOPES, WAWF)

- Identify # of connection errors

- Identify connection availability

- Identify performance delta per systems engineer guidance

2.1.5 User Generated

Reports

Monthly/Per System Change

List

- Critical system reports accessed by stakeholders

- Baseline time to run report

- Identify monthly or recent GAT test results

- Identify performance delta per systems engineer guidance

2.2 Standard System Profile

The standard system profile metrics characterize an IT system to help Product Management Office and associated system integrators to understand and define system behavior.

Reporting Frequency

Reporting Details Metric Priority

2.2.1 Total # Users Monthly Trend Chart

- (Polling Rate) 1st day of month

- (Duration) 12 months

- (X axis) Month (Y axis) #

Users

2.2.2 Total # Active

Users

Monthly Trend Chart

- (Polling Rate) 1st day of month

- (Duration) 12 months

- (X axis) Month (Y axis) # Active Users

2.2.3 Max #

Concurrent Connections

Monthly - Total # of connections

- Date & time of activity

2.2.4 Avg #

Concurrent Connections

Monthly Trend Chart

- (Polling Rate)

Continuous Monitoring

- (Duration) 1 Month

- (X axis) Day (Y axis) #

Connections

2.2.5 System

Throughput (mb/s)

Monthly Trend Chart

- (Polling Rate)

Continuous Monitoring

- (Duration) 4 x 1 Week

Charts

- (X axis) Day/Hour (Y axis) mb/s

2.2.6 Standard System

Maintenance Windows

Monthly - Date(s)

- Time of Day

- Duration

2.2.1 Total # of Users: This defines the total number of users who have account access to the system. For public web based systems that are currently hosted or will be hosted in the future by PM TFITS, total number of unique users accessing the system is acceptable.

2.2.2 Total # Active Users: This metric quantifies the total number of active users in the reporting period, where active is defined as a user who has logged into the system.

2.2.3 Max # Concurrent Connections: This metric defines the number of simultaneous, or concurrent, sessions or connections made to a system during a reporting period. Maximum number of connections should be labeled with a date and time stamp.

2.2.4 Average # Concurrent Connections: This metric defines the average number of sessions or connections expected to be open with the system at a given time.

2.2.5 System Throughput (mb/s): This metric defines the network/system throughput based upon user activity and requests. System Throughput is measured in mb/s and shall be plotted on a line chart that shows time of day and day of the week.

2.2.6 Standard System Maintenance Window(s): All PdM TFITS projects shall report a standard maintenance window with time of day and duration of window. By reporting this information, stakeholder notifications and planning can occur that helps reduce impact of planned system downtime.

2.3 Service Operations Metrics

Service Operations metrics show the volume of customer requests and interaction, as well as the efficiency in which support teams can accommodate those requests.

Service operations metrics will provide key performance indicators that help Project Managers to determine the proper level of effort to support a system, which in turn will drive program cost estimates and future forecasting for capacity needs.

Detailed service operations metrics can also provide key indicators for engineers and architects to identify systemic problems impacting stakeholder experience.

Reporting Frequency

Reporting Details Metric Priority

2.3.1 Total # Incident

Requests

Monthly Table

- (Polling Rate) Last day of performance period

- Categorize by type

2.3.2 Total #

Active/Open Requests at End of Reporting Period

Monthly Table

- (Polling Rate) Last day of performance period

- Categorize by type

- List request age

- List request description

2.3.3 Total # of Incident

Requests Closed

Monthly Table

- (Polling Rate) Last day of performance period

- Categorize by type

2.3.4 Mean Time to

Resolve Incidents

Monthly Table

- (Polling Rate) Last day of performance period

- Categorize by type

2.3.5 Total Time Spent

Per Incident Request

Monthly Table

- (Polling Rate) Last day of performance period

- Categorize by type

2.3.6 Total # of ECPs Monthly Table 3

Generated from Incident Requests

- (Polling Rate) Last day of performance period

- List ECP #

- List incident request #

2.3.1 Total # Incident Requests: This metric shall reflect the number of stakeholder requests to the system support team for help/assistance in remediating incidents, problems, or system failures. Requests shall be categorized by ‘Type’, where ‘Type’ of request is defined by the system PjM.

2.3.2 Total # Active/Open Requests at End of Reporting Period: This defines the number of open requests at the end of each period by: type, age, and a brief description of the open service request.

2.3.3 Total # of Incident Requests Closed: This number tells the total count of incident requests closed during the reporting period.

2.3.4 Mean Time to Resolve Incidents: This metric identifies the average amount of time it takes from opening incident requests to the time of closure.

2.3.5 Total Time Spent Per Incident Type: This metric identifies the total amount of time system support staff spent resolving all incidents within each project defined category. Note that it is acceptable to report total time spent by ‘Type’ category, it is not necessary to be specific for every request unless designated by the system PjM.

2.3.6 Total # ECPs Generated from Incident Request: This metric identifies the total number of incident requests that were properly correlated to system problems necessitating change, with corrective actions documented into an Engineering Change Proposal (ECP).

2.4 Engineering/Integration Metrics

Performance metrics within the Engineering & Integration category are geared towards engineering process, planning and integration efficiency. Engineering performance metrics are tailored to program System Engineering Technical Reviews (SETR) events and seek to identify sustainability of the current baseline design.

ID # Performance Metric Reporting Frequency

Reporting Details Metric Priority

2.4.1 Total # New ECPs Monthly Table

- (Polling Rate) Last day of reporting period

- List each unique

ECP

2.4.2 Total # Open ECPs Monthly Table

- (Polling Rate) Last day of reporting period

- List each open ECP

- List status of ECP

2.4.3 Total # Closed ECPs Monthly Table

- (Polling Rat) Last day of reporting period

- List each closed

ECP

- List description of

ECP

2.4.4 Total # ECPs rejected

at ERB/CCB

Monthly Table

- (Polling Rate) Last day of reporting period

- List rejected ECPs

- List reason for rejection

2.4.5 Total # Backed-Out

ECPs

Monthly Table

- List # ECPs backed-out

- Provide description as to why back-out occurred

2.4.6 Total #

Emergency/Unplanne d Changes

Monthly Table

- List # emergency changes

- Provide description of emergency change

- Date/time change occurred

2.4.7 Total # FRACAS

Reports

Per Failure

Table

- List # FRACAS reports

- Provide description of system failure

- Date/time failure occurred

2.4.8 Total # GAT Test Cases

Executed

Per Release

Table

- # GAT test cases executed

2.4.9 Total # GAT Failures Per

Release

Table

- # failed test cases executed

- Description and test ID #

2.4.10 Total # Defects Monthly Trend Chart

- # identified defects

- Defect description

2.4.11 Total # Defects Closed Monthly Trend Chart

- # defects closed

- Defect ID & description

2.4.12 Total # New Defects Per

Release

Trend Chart

- Total # new defects

- Description of new defect

- ECP or change causing defect (if applicable)

2.4.13 Total # RFAs / SETR

Event

Per SETR Event

Table

- # RFAs categorized by

SETR

- RFA description

- RFA open date

2.4.1 Total # New ECPs: This metric indicates the total number of new ECPs submitted during the reporting period. These ECPs will be categorized by severity level.

2.4.2 Total # Open ECPs: This metric identifies the total number of open ECPs at the end of the reporting period. These ECPs will be categorized by severity level.

2.4.4 Total # Closed ECPs: This metric identifies the total number of closed ECPs at the end of the reporting period. These ECPs will be categorized by severity level.

2.4.5 Total # ECPs Backed-Out: This metric indicates the number of ECP changes executed or in in process of execution and eventually backed-out or rolled-back due to technical issues or newly introduced defects. A description must be provided with each ECP.

2.4.6 Total # Emergency/Unplanned Changes: This metric will present leadership with a view of the number of changes to the system executed outside the scope of standard maintenance windows and results from customer problems and incidents.

Unplanned or emergency changes may still follow the ECP and SETR process, however these are driven by defects or failures that require unplanned cycles to remediate.

2.4.7 Total # FRACAS Reports: Failure Reporting and Corrective Action System (FRACAS) are generated upon system failures: system failures are identifies as 1) total outages 2) failures of a service within the system that impact its ability to meet customer requirements. This metric identifies the total # of FRACAS reports and provides a summary of each.

2.4.8 Total # GAT Tests Executed: This metric identifies the total number of GAT tests executed during the reporting period.

2.4.9 Total # GAT Failures: This metric identifies the total number of failures experienced during GAT test execution.

2.4.10 Total # Defects: This metric indicates the total number of known defects within application code or in network/hardware resources. Each defect should provide a brief synopsis of the defect and correlate to an existing ECP or release in which it will be corrected.

2.4.11 Total # Defects Closed: This metric identifies the total number of defects closed in the reporting period. A brief synopsis of each defect should be provided along with the ECP number closing that defect.

2.4.12 # New Defects Introduced: This metric indicates the number of defects introduced after a release to production or identified by users/operators during the reporting period. Each new defect should provide a brief synopsis of the defect, change or ECP that introduced the defect, and whether it is scheduled in a future release for remediation.

2.5 Compliancy Metrics

System compliancy metrics demonstrate compliancy with imposed federal mandates and program requirements. At any time, analyzing compliancy metrics can provide insight to the overall system security posture, as well as overall sustainability metrics useful in measuring personnel performance and aptitude, in addition to cost forecasting and modeling.

ID # Performance Metric Reporting Frequency

Reporting Details Metric Priority

2.5.1 % STIG Compliant Monthly - (Polling Rate) Weekly 1

2.5.2 % IAVM Compliant Monthly - (Polling Rate) Weekly 1

2.5.3 Total # IA

Vulnerabilities Open

Weekly - Categorized by Severity Level (CAT I, II, III, IV)

2.5.4 Total # IA

Vulnerabilities Remediated

Monthly - Categorized by Severity Level (CAT I, II, III, IV)

2.5.5 Code Review(s) Monthly List

- # of code reviews performed

- Total # of code review findings by severity level

- # of code security findings remediated during reporting period

2.5.1 % STIG Compliant: This metric identifies the security vulnerabilities from a Security Technical Implementation Guide (STIG) perspective. The USMC provides tools to support teams to assist in the automated collection of this information.

2.5.2 % IAVM Compliant: This metric identifies the security vulnerabilities from an Information Security Vulnerability Alert (IAVM) perspective. IAVMs consist of Information Security Vulnerabilities (IAVA) and Information Security Vulnerability Bulletins (IAVB). The USMC provides tools to support teams to assist in the automated collection of this information.

2.5.3 Total # IA Vulnerabilities Open: This metric identifies the total number of security vulnerabilities present within the application system. Total vulnerabilities should be reported by total number in each category severity level (CAT).

2.5.4 Total # IA Vulnerabilities Remediated: This metric identifies to program management and IA personnel the total progress and efficiency with which engineering and administrators can identify, assess, test, implement, and close vulnerabilities.

2.6 System Performance Metrics

System performance metrics form the basis for technical measurement. These metrics directly correlate to how back-end server and software code are interacting with all elements to produce an expected user experience. To conduct true system performance, all system services must undergo decomposition down to system elements, where traceability can be established for root cause analysis on partial outages or slow performance to a specific web query or request.

Reporting Frequency

Reporting Details Metric Priority

2.6.1 System Availability Monthly - (Polling Rate)

Continuous Monitoring

2.6.2 Total Downtime

Per Period

Monthly - (Polling Rate) Continuous monitoring

2.6.3 Total Planned

Downtime

Monthly - (Polling Rate) Last day of reporting period

- Total # hours planned

2.6.4 Total Unplanned

Downtime

Monthly - (Polling Rate) Continuous Monitoring

- Total # hours unplanned

2.6.5 Downtime During

Peak Hours

Monthly - (Polling Rate) Continuous monitoring during peak performance times

2.6.6 System Element

Availability

Monthly - (Polling Rate) Continuous Monitoring

- Database Tier Availability

- Web Tier Availability

- Application Tier

Availability

- Network Availability

- Storage/SAN

Availability

2.6.7 Mean Time to

Restore

Per Incident

- List each failure

- List time to repair each failure

- Average time to restore all outages

2.6.8 Backup &

Restoration Success Rate

Monthly Table

- (Polling Rate) Verify after each planned backup or restore operation

- Total # backup attempts

- Total # backup failures

- Total # restore attempts

- Total # restore failures

2.6.9 Disk Storage

Utilization

Monthly Table

- (Polling Rate) Last day of reporting period

- Categorize storage space Available by drive/volume

- Categorize storage space Consumed by drive/volume

- Identify total storage available on Hardware storage device(s) (unallocated storage)

2.6.10 Memory Utilization Monthly Table

- (Polling Rate)

Continuous monitoring

- List average utilization by system server

2.6.11 CPU Utilization Monthly Table

- (Polling Rate)

Continuous monitoring

- List average utilization by system server

2.6.1 System Availability: This metric indicates the overall % availability of the system to its stakeholders. % Availability must account for all hours of each day, regardless if standard usage of the system is during peak performance hours.

2.6.2 Total Downtime per Period: This metric will show in Hours/Minutes the total amount of downtime the system experienced over the reporting period.

2.6.3 Total Planned Downtime per Period: This metric will show of the total downtime, how much of that downtime was planned; ie. System maintenance window.

2.6.4 Total Unplanned Downtime per Period: This metric will show of the total downtime, how much of that downtime was unplanned; ie. System outage or failure.

2.6.5 Downtime During Peak Hours: This metric indicates the total downtime experienced during peak system usage and performance hours. Peak hours are determined through metric 2.1.5: System Throughput.

2.6.6 System Element Availability: This metric indicates subsystem element availability of the application system. Categories include 1) Database availability 2) Web Tier Availability 3) Application Tier Availability 4) Network Availability 5) Storage/SAN availability.

2.6.7 Mean Time to Restore: This metric indicates the average time it takes to restore the application system from failure. MTTR only factors system failures; it does not factor incidents or problems that do not cause a failure.

2.6.8 Backup and Restoration Success Rate: This metric indicates the total # of backups taken during the reporting period, along with the success rates of those backups. This metric should also indicate the total number of restore procedures conducted during the period and the success rate of those restore procedures.

2.6.9 Disk Storage Utilization: Disk storage utilization is an important metric for capacity planning. This information will be provided in a table, broken down by: 1) Raw storage available 2) Storage allocated (by volume) 3) Storage consumed (by volume).

2.6.10 Memory Utilization: Memory utilization is an important metric for capacity planning. This information will be provided in a table for each system server and should show 1) observed spikes in memory utilization with date/time 2) average memory usage on the server.

2.6.11 CPU Utilization: CPU utilization is an important metric for capacity planning.

This information will be provided in a table for each system server and should show

1) observed spikes in CPU utilization 2) average CPU utilization per server

Appendix A

Appendix A contains a populated TFITS Performance Measurement form. This form has been populated with representative data to demonstrate the proper method of data collection and reporting.

PdM TFITS Monthly Performance Measurement Reporting Form

Project: TRAP

Reporting Date: 12/5/2013

1.0 Application / System Specific Metrics

Please note that these are sample application metrics not properly mapped to a specific performance element of an existing TFITS system. These are reflective however to types of application functions throughout the portfolio that will be recorded and monitored.

Search Capability Baseline

Search Query Response Time

Baseline Report Query Time (Sec) + Acceptable

Deviation

Last GAT or Monthly Evaluation Testing (Sec)

General Officer Search 14.9 ± 1.9 15.5

Senior Enlisted Search 21.4 ± 2.6 20.4

Civilian Personnel Search 29.1 ± 3.4 31.5

Web Page Load Times Web Page Load Time Baseline

(Sec) + Acceptable Deviation

Last GAT or Monthly Evaluation Testing (Sec)

Commanders Dashboard 4.3 ± 1.4 9.3

Finance Reporting Dashboard

9.2 ± 3.4 19.5

Joint Force Planning Page 5.5 ± 3.4 5.1

General’s Blog Website 3.0 ± 2.4 4.5

Workflow Execution Baseline

Workflow Name Baseline Workflow Execution Time +

Acceptable Deviation

Last GAT or Monthly

Evaluation Testing

Workflows Executed /

Failures

Workflow – Submit User Request

8.4 ± 2.6 10.8 49 / 3

Workflow - Create New TPS Report

31.5 ± 9.6 34.5 17 / 0

Workflow – Notify All Users (Alert)

74.8 ± 9.4 246.7 4 / 1

Workflow – Create New Calendar Entry

5.8 ± 2.6 6.5 85 / 0

2.0 SYSTEM PROFILE INFORMATION

Last Month Current

Month Total # of Users 54,213 54,572 Total # of Active Users 43,480 46,442

Month Max # of Concurrent Connections 5,127

10/22/2013

1401 EST

5,417 11/16/2013

1332 EST

Average # of Concurrent Connections 3,608 3,691

Month System Throughput (mb/s) 44.14 mb/s 42.03 mb/s

Standard System Maintenance Window 2nd & 4th Thursday of Month

2100 – 0200 EST

30,000

35,000

40,000

45,000

50,000

55,000

60,000

D ec

-1

Ja n

-1

F eb

-1

M ar

-1

A p r-

M ay

-1

Ju n

-1

Ju l-

A u g-

Se p

-1

O ct

-1

N o v -1

D ec

-1

Total # Users

Total # Active Users

2,000

2,500

3,000

3,500

4,000

Average # of Concurrent Connections

# of Concurrent Connections

D ec

-1

Ja n

-1

F eb

-1

M ar

-1

A p r-

M ay

-1

Ju n

-1

Ju l-

A u g-

Se p

-1

O ct

-1

N o v -1

D ec

-1

System Throughput mb/s

System Throughput mb/s

3.0 SERVICE OPERATIONS METRICS

Total # Incident Requests

Type

Total Active

Total

Closed

Mean Time to Resolve

Total Time Per Request

# ECPs Generated from Requests

Account Creation

3 47 1.4 Hours .2 Hours 0

Login Error 1 13 .67 Hours .5 Hours 0 Report/Form Error

2 0 6.4 Days 3.3 Days 1

SCR02479

Website Unavailable

0 11 1.1 Hours .6 Hours 0

User Training 4 0 N/A N/A 0 Network Connectivity

0 3 4.4 Hours 3.4 Hours 0

Database Error

0 2 2.3 Hours 1.7 Hours 2

SCR02479

SCR10014

General Error 3 9 21.6 Hours 7.1 Hours 6

SCR09004

SCR09018

SCR09192

SCR09898

SCR09901

SCR09990

Active Incident Descriptions (Open Beyond 48 Hours)

Type Incident # Description Status Account Creation

INC40989

Generate new account for Mr.

Doe

Awaiting POC approval(s)

INC41334

Generate new account for Ms.

INC42808 Generate new account for Cpl Don

Login Error

INC41819 User unable to login after CAC renewal

Verified EDIPI, user working with DEERS to ensure PKI certificate active, user cannot login to other PKI enabled sites.

Report INC41747

Form Error INC41804

User Training

INC39880 Maj John requesting training on calendar module

Awaiting users return from TAD, will schedule upon return

INC40123 Mr. Bills requesting training on RSS capability

Awaiting COR approval to allocate hours for training

INC41552 LCpl Peters requesting admin training

Verifying with II MEF POC of LCpl Peters role and need for admin training.

Awaiting response.

INC41713 Ms. Thomas requesting training on account request process.

Working. Generating Wiki site with online training instructions.

General Error

INC40889 Excel Spreadsheet Widget non-functional.

Working. Determined one web server experiencing issue.

Server removed from web-pool until fixed.

INC40632 RSS widget non-functional on General’s dashboard.

Working. Determined issue began post dashboard migration to new website.

Examining GUIDs and URL relations.

INC40421 Reported that budgeting form on finance site miscalculating

4.0 Engineering & Integration Metrics

Total # New ECPs ECP Description Total # of

Open ECPs

Open ECP #(s)

2 SCR01521 – New enlisted program SOUs SCR01363 – Modify web query tool to show class waivers

7 All ECPs pending release 2.1.3.4

SCR01521

SCR01519

SCR01363

SCR01489

SCR01422

SCR01491

SCR01492

Total # Closed ECPs Closed ECP #(s) Total # ECPs

Rejected ECP #(s)

Rejected at ERB

5 ECPs closed during release 2.1.3.2

SCR01421 SCR01424

SCR01455

ECPs closed during release 2.1.3.3

SCR01449

1 SCR01509 –

design deemed incomplete due to lack of load balancing configurations

Total # Unplanned/Emergen cy Changes

Unplanned/Emergency Change Description

Total #

FRACAS

Reports

FRACAS Report Details

1 Workaround applied to server APPSERV003 to fix web.config file corruption.

Server taken offline and tested prior to release back into production.

2 FRACAS

11/17/2013-01 System search service failed.

Search index corrupted, rebuilt index by running new scan.

FRACAS

11/22/2013-01 System outage.

Reported network loss from demarcation point, service restored by network provider.

Total # GAT Tests Executed

Total # GAT Failures Total # Open

Defects

Defect ID & Description

Release 2.1.3.2 & 2.1.3.3

14 Total GAT test cases

0 Failures identified

ID# 00117

Defect Activity Tracker

Total # Defects Total # New Defects Total # RFAs /SETR Event

Open at End of Period Closed this Period New this Period

Closed

ID#00115

ID#00116

0 New Defects Identified

Held Critical Design Review

(CDR) 11/3/2013

Critical RFAs – 6 Non-Critical RFAs – 2 Request for Information – 1 Out of Scope - 0

5.0 Compliancy Metrics

% STIG COMPLIANT 86%

% IAVM COMPLIANT 94%

Server Total # Vulnerabilities Open

Total # Vulnerabilities Remediated

WEBSERV001 CAT I - 1

CAT II - 8

CAT III - 13

CAT IV – 0

CAT I - 1

CAT II - 3

CAT III - 4

CAT IV – 0

WEBSERV002 CAT I - 1

CAT II - 7

CAT III - 13

CAT IV – 0

CAT I - 1

CAT II - 3

CAT III - 3

CAT IV - 0

APPSERV001 CAT I - 3

CAT II - 9

CAT III - 5

CAT IV – 0

CAT I - 2

CAT II - 1

CAT III - 1

CAT IV – 0

APPSERV002 CAT I - 3

CAT II - 13

CAT III - 4

CAT IV - 0

CAT I - 1

CAT II - 1

CAT III - 1

CAT IV – 0

DBSERV001 CAT I - 2

CAT II - 5

CAT III - 7

CAT IV - 0

CAT I - 0

CAT II - 1

CAT III - 0

CAT IV – 0

DBSERV002 CAT I - 1

CAT II - 5

CAT III - 11

CAT IV – 0

CAT I - 0

CAT II - 1

CAT III - 0

CAT IV - 0

TOTAL : CAT I - 11

CAT II - 47

CAT III - 53

CAT IV - 0

CAT I - 5

CAT II - 9

CAT III - 9

CAT IV - 0

6.0 System Performance Metrics

System Availability 99.79% Total Downtime 91 Minutes Total Planned Downtime

8 Minutes

Total Unplanned Downtime

83 Minutes 11/23/2013 2202 – 2325 EST

Downtime During Peak Hours (0900 – 1600

EST)

0 Minutes

System Element Availability

Database Tier: 100% Web Tier: 100% Application Tier: 100% Network Availability: 99.79% SAN/Storage Tier: 100%

Mean Time to Restore FRACAS 11/22/2013-01 : 83 Minutes MTTR: 83 Minutes

Backup and Restore Success Rate

Total Backups Taken: 30 Backups Backup Failures: 1 Backup Success Rate: 96.7%

Total Restore Procedures: 2 Restore Failures: 0 Restore Success Rate: 100%

DISK STORAGE UTILIZATION

Storage Available (Unallocated) EMC Clariion Appliance

4.70 TB Raw (Estimated) 2.70 TB @

RAID 5

Server Storage Allocated

Storage Used Storage Available

WEBSERV001 C:\ 200 GB

D:\ 350 GB

E:\ 100 GB

C:\ 88 GB

D:\ 275 GB

E:\ 91 GB

C:\ 118 GB

D:\ 75 GB

E:\ 9 GB

WEBSERV002 C:\ 200 GB

D:\ 350 GB

E:\ 100 GB

C:\ 89 GB

D:\ 260 GB

E:\ 17 GB

C:\ 111 GB

D:\ 90 GB

E:\ 83 GB

APPSERV001 C:\ 200 GB

D:\ 350 GB

E:\ 100 GB

C:\ 95 GB

D:\ 306 GB

E:\ 74 GB

C:\ 105 GB

D:\ 44 GB

E:\ 26 GB

APPSERV002 C:\ 200 GB

D:\ 350 GB

E:\ 125 GB

C:\ 95 GB

D:\ 323 GB

E:\ 74 GB

C:\ 105 GB

D:\ 27 GB

E:\ 51 GB

DBSERV001 C:\ 200 GB

D:\ 350 GB

E:\ 250 GB

C:\ 87 GB

D:\ 348 GB

E:\ 72 GB

C:\ 113 GB

D:\ 2 GB

E:\ 178 GB

J:\ 500 GB

K:\ 500 GB

J:\ 244 GB

K:\ 417 GB

J:\ 256 GB

K:\ 83 GB

DBSERV002 C:\ 200 GB

D:\ 350 GB

E:\ 250 GB

J:\ 500 GB

K:\ 500 GB

C:\ 92 GB

D:\ 292 GB

E:\ 134 GB

J:\ 424 GB

K:\ 280 GB

C:\ 108 GB

D:\ 58 GB

E:\ 116 GB

J:\ 76 GB

K:\ 220 GB

Total Storage: 6,225 GB 4,652 GB

CPU & Memory Utilization

Server Average CPU Utilization

Observed CPU Spikes

Average Memory

Utilization

Observed Memory Spikes

WEBSERV001 42% 73% 12% 39%

WEBSERV002 23% 52% 19% 44%

APPSERV001 9% 31% 14% 34%

APPSERV002 12% 39% 22% 51%

DBSERV001 55% 89% 43% 74%

DBSERV002 49% 80% 59% 91%

SubmitButton1: