[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-seo-241498-105":3,"detail-sidebar-cat-1-en-105":80,"doc-detail-241498-en":126},{"code":4,"msg":5,"data":6},0,"ok",{"site_id":7,"language":8,"slug":9,"title":10,"keywords":11,"description":12,"schema_data":13,"social_meta":73,"head_meta":75,"extra_data":77,"updated_unix":79},105,"en","ausnet-kpmg-ot-testing-regime-supplementary-report-recommendations","AusNet KPMG OT Testing Regime Supplementary Report - Recommendations","","Appendix C presents an integrated set of observations and recommendations for the AusNet Outage Tracker incident, covering both likely root causes and remediating actions. It identifies issues across caching capacity under traffic surges, unexpected data growth in CosmosDB, and coupled Azure deployments that limit independent scaling. It also highlights gaps in the testing regime and recommends a complete set of testing types, including performance and scaling validation, alongside stronger governance for configuration changes and business continuity readiness.",{"@graph":14,"@context":72},[15,34,55],{"@type":16,"itemListElement":17},"BreadcrumbList",[18,23,27,31],{"item":19,"name":20,"@type":21,"position":22},"https://docshare.wps.com","Home","ListItem",1,{"item":24,"name":25,"@type":21,"position":26},"https://docshare.wps.com/template/","Template",2,{"item":28,"name":29,"@type":21,"position":30},"https://docshare.wps.com/template/presentations/","Presentations",3,{"item":32,"name":10,"@type":21,"position":33},"https://docshare.wps.com/template/ausnet-kpmg-ot-testing-regime-supplementary-report-recommendations/241498/",4,{"url":32,"name":10,"@type":35,"image":36,"author":41,"headline":10,"publisher":44,"fileFormat":47,"inLanguage":8,"description":12,"dateModified":48,"datePublished":49,"encodingFormat":47,"isAccessibleForFree":50,"interactionStatistic":51},"DigitalDocument",{"url":37,"@type":38,"width":39,"height":40},"https://docshare.wps.com/thumbnails/ausnet-kpmg-ot-testing-regime-supplementary-report-recommendations/241498.png","ImageObject",442,249,{"name":42,"@type":43},"Terk","Person",{"url":19,"name":45,"@type":46},"DocShare","Organization","application/pdf","2026-10-11","2026-09-12",true,{"@type":52,"interactionType":53,"userInteractionCount":22},"InteractionCounter",{"@type":54},"ViewAction",{"@type":56,"mainEntity":57},"FAQPage",[58,64,68],{"name":59,"@type":60,"acceptedAnswer":61},"What root cause is linked to cache performance during high traffic?","Question",{"text":62,"@type":63},"Redis cache could not handle traffic surges and the resulting high incident volume, reducing the ability of the Outage Tracker to retrieve data rapidly under load.","Answer",{"name":65,"@type":60,"acceptedAnswer":66},"Which recommendation addresses unexpected CosmosDB data growth?",{"text":67,"@type":63},"Review the end-to-end data handling and adopt patterns such as pagination, lazy-loading, or de-batching to control ingestion size during periods that create elevated incidents.",{"name":69,"@type":60,"acceptedAnswer":70},"How should future testing be improved according to the document?",{"text":71,"@type":63},"Validate the testing approach for regime completeness and conduct unit, functional, regression, integration, and performance tests, aligned with AusNet change policies and capacity planning procedures.","https://schema.org",{"og:url":32,"og:type":74,"og:title":10,"og:site_name":45,"og:description":12},"article",{"robots":76,"canonical":32},"index,follow",{"doc_id":78,"site_id":7},241498,1791719459,{"code":4,"msg":81,"data":82},"success",[83,87,92,97,102,107,112,117,122],{"id":84,"doc_module":22,"doc_module_name":25,"category_name":29,"show_sort_weight":85,"slug":86},11,90,"presentations",{"id":88,"doc_module":22,"doc_module_name":25,"category_name":89,"show_sort_weight":90,"slug":91},12,"Resumes",80,"resumes",{"id":93,"doc_module":22,"doc_module_name":25,"category_name":94,"show_sort_weight":95,"slug":96},14,"Invoices",70,"invoices",{"id":98,"doc_module":22,"doc_module_name":25,"category_name":99,"show_sort_weight":100,"slug":101},15,"Posters",60,"posters",{"id":103,"doc_module":22,"doc_module_name":25,"category_name":104,"show_sort_weight":105,"slug":106},16,"Social Media",50,"social-media",{"id":108,"doc_module":22,"doc_module_name":25,"category_name":109,"show_sort_weight":110,"slug":111},17,"Forms",40,"forms",{"id":113,"doc_module":22,"doc_module_name":25,"category_name":114,"show_sort_weight":115,"slug":116},18,"Letters",30,"letters",{"id":118,"doc_module":22,"doc_module_name":25,"category_name":119,"show_sort_weight":120,"slug":121},21,"Paper Templates",5,"papers-templates",{"id":123,"doc_module":22,"doc_module_name":25,"category_name":124,"show_sort_weight":4,"slug":125},158,"General","general-158",{"code":4,"msg":81,"data":127},{"doc_id":78,"user_id":128,"nickname":42,"user_avatar":129,"doc_module":22,"category_id":84,"category_name":29,"doc_title":10,"doc_description":12,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":120,"is_deleted":4,"is_public":22,"is_downloadable":22,"audit_status":22,"page_count":135,"language":136,"language_code":8,"site_id":7,"html_lang":8,"table_of_contents":137,"faqs":138,"seo_title":139,"seo_description":12,"update_tm":140,"read_time":30},1099525198933,"https://ap-avatar.wpscdn.com/davatar_155a257f0dc6eb9ab79c44ca47cae57d","Appendix C  \nIntegrated view of all observations and recommendations (1/7)  \nObservations Ref \\# Observation / Recommendations  \n\n| Likely Root Cause observations\u003Cbr>Observations that have direct contribution to the Outage Tracker incident. | OBS1.1 | Observation: Redis cache was unable to handle a surge in user traffic and high number of incidents.\u003Cbr>Recommendations:\u003Cbr>• (R1) Revisit the requirements and design decisions around the caching to ensure the solution is resilient in high traffic scenarios. This should include validation of the accountability of the requirements with the business and ensure traceability through design and test. For instance, the Outage Tracker is expected to retrieve data rapidly from the cache, but it’s not expecting the cache to scale across the network for better fault tolerance. These requirements will help in choosing the right technology and caching mechanism for the Outage Tracker.\u003Cbr>• (R2) Review the design to consider using separate cache partitions for each website. |\n| --- | --- | --- |\n|  | OBS1.2 | Observation: Due to a high number of incidents, the size of the data ingested in CosmosDB increased unexpectedly that contributed towards unavailability of the Outage Tracker Service.\u003Cbr>Recommendations:\u003Cbr>• (R3) Review the data aspect of the end-to-end solution and consider implementing patterns like pagination, lazy-loading or de-batching.\u003Cbr>• (R4) Review the testing approach and identify the gaps in testing to ensure defects are rectified early in the delivery process. It is recommended that all future Outage Tracker testing be validated for testing regime completeness and conduct (at a minimum) the following testing types. Types should be conducted in line with AusNet's change policies and procedures and in consideration of change types and change risk. Additionally, Performance Testing should be conducted in line with AusNet’s capacity planning policies and procedures (annually at a minimum) . (also covered under OBS2 .4)\u003Cbr>o Unit Testing – To ensure the code developed is validated for expected behaviour\u003Cbr>o Functional Testing – To ensure the changes made meet the functional requirements\u003Cbr>o Regression Testing – To ensure code or functionality developed does not adversely impact other components\u003Cbr>o Integration Testing – To ensure the code developed is functioning end-to-end between all tech components\u003Cbr>o Performance Testing (including testing the scaling of the infrastructure)– To ensure all non-functional requirements are addressed |\n|  | OBS1.3 | Observation: Outage Service and Outage EAI Service are deployed as a coupled application on Azure App services sharing the same webapp.\u003Cbr>Recommendation:\u003Cbr>• (R5) Conduct an assessment to decouple the Outage Service API that is fetching the data from Redis cache from the Outage EAI Service that is interacting with EAI and Cosmos DB. This will ensure both the webapps can be scaled independently during peak hours. |\n|  | OBS1.4 | Observation: Outage Tracker Service experienced high CPU usage and one of the contributory factors was the underlying code that was not following the best practices of asynchronous programming.\u003Cbr>Recommendation:\u003Cbr>• (R6) Conduct and in-depth review of the current code of the Outage Tracker Service to follow the best practices as advised by Microsoft. |\n\n©2024 KPMG, an Australian partnership and a member firm of the KPMG global organisation of independent member firms affiliated with KPMG International Limited, a private English company limited by guarantee. All rights reserved. The KPMG name and logo are trademarks used under license by the independent member firms of the KPMG global organisation.  \nDocument Classification: KPMG Confidential  \nLiability limited by a scheme approved under Professional Standards Legislation.  \n43  \nAppendix C  \nIntegrated view of all observations and recommendations (2/7)  \nObservations Ref \\# Recommendations  \n\n| Remediating Action observations\u003Cbr>Observations on remedia","cbCaithSOK8dfjRW","https://ap.wps.com/l/cbCaithSOK8dfjRW","pdf",105282,7,"English","# Integrated view of all observations and recommendations (1/7)\n## Likely Root Cause observations\n### OBS1.1 to OBS1.4\n## Remediating Action observations\n### OBS2.1 to OBS2.4","[{\"question\":\"What root cause is linked to cache performance during high traffic?\",\"answer\":\"Redis cache could not handle traffic surges and the resulting high incident volume, reducing the ability of the Outage Tracker to retrieve data rapidly under load.\"},{\"question\":\"Which recommendation addresses unexpected CosmosDB data growth?\",\"answer\":\"Review the end-to-end data handling and adopt patterns such as pagination, lazy-loading, or de-batching to control ingestion size during periods that create elevated incidents.\"},{\"question\":\"How should future testing be improved according to the document?\",\"answer\":\"Validate the testing approach for regime completeness and conduct unit, functional, regression, integration, and performance tests, aligned with AusNet change policies and capacity planning procedures.\"}]","AusNet KPMG OT Testing Regime Supplementary Report - Recommendations | PDF",1789176291]