Laserfiche WebLink
REV: 10-03-24 MI <br />On an annual basis, Neighborly Software tests its Disaster Recovery capabilities by triggering a manual <br />fail over from its primary data center to the backup data center <br />Outage Procedures <br />In the event of an outage affecting one or all service components described above, the first informed <br />technical staff member will initiate and all-hands Teams or Zoom call for the full IT staff including the <br />following: <br />Chief Technology Officer <br />Security Engineer <br />All Software Developers <br />VP of Client Operations <br />Director of Client Success <br />This team is identified as the Outage Team. An initial evaluation of the outage is performed to determine <br />the likely cause, with an emphasis on determining if the outage occurred due to availability of Azure <br />resources or an internal software error. <br />The team will review any recent maintenance activity along with recent hotfix or release deployments. If <br />the cause is determined to be internal software, the development team will work to triage the issue and <br />deploy a software or database fix as appropriate. As deployments are conducted during maintenance <br />windows overnight hours, the potential for an internal software issue is low. <br />Additionally, a member of the development team will immediately begin reviewing Azure Health Status <br />at https://status.azure.com/en-us/status as well as https://downdetector.com. In our experience, Down <br />Detector is more likely to provide insight into Azure regional outages in a more timely manner than <br />Azure Health Status. <br />A determination will also be made whether the outage impacts all client pods or is limited to one pod in <br />particular. All client pods are based in the same geo-redundant data centers. If it is determined that the <br />outage is Azure related, a system test of all system components will be conducted, with a different <br />software developer testing the availability of Application Services, SQL databases and File Storage to <br />determine the affected services. <br />Client Notification Procedures <br />If the outage occurs for longer than 2 minutes, the VP of Client Operations will begin loading the client <br />notification system which is managed by Cloudflare. Existing outage templates are available with the <br />Audience updated weekly to include Neighborly Software client administrators. An initial notification is <br />sent out immediately informing administrative users that we are aware of the outage, and that additional <br />notifications will occur hourly with additional details until the issue is resolved. A final notification is <br />sent when the outage is resolved or mitigated. <br />Failover Procedures <br />Application Services <br />1. The Principal Architect or designated Senior Software Engineer will load the Azure Portal and <br />load the Azure Traffic Manager blade. <br />2. On the Endpoints tab, the designated resource will change the Priority of the affected Endpoint to <br />a numerical value higher than the backup endpoint. <br />ATTY/AGR.2024.180/Neighborly Software (Page 24 of 26)