├── GuardrailCrosswalks
├── AzureCrosswalk.xlsx
└── README.md
├── hybrid_ref_arch
├── Hybrid Work Ref Arch Diagram.png
└── README.md
├── cloud cost
├── GC Cloud Cost Management Playbook Published July 2022.pdf
└── Guide sur la gestion des coûts de l’informa tique en nuage du gc publie julliet 2022.pdf
├── earb-forward-agenda
└── index.html
├── azure-pipelines.yml
├── azure-pipelines-past-sessions.yml
├── README.md
└── gc_cloud_cost_management_guidance
└── readme.md
/GuardrailCrosswalks/AzureCrosswalk.xlsx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/canada-ca/TBS-OCIO-ESP/HEAD/GuardrailCrosswalks/AzureCrosswalk.xlsx
--------------------------------------------------------------------------------
/hybrid_ref_arch/Hybrid Work Ref Arch Diagram.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/canada-ca/TBS-OCIO-ESP/HEAD/hybrid_ref_arch/Hybrid Work Ref Arch Diagram.png
--------------------------------------------------------------------------------
/cloud cost/GC Cloud Cost Management Playbook Published July 2022.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/canada-ca/TBS-OCIO-ESP/HEAD/cloud cost/GC Cloud Cost Management Playbook Published July 2022.pdf
--------------------------------------------------------------------------------
/cloud cost/Guide sur la gestion des coûts de l’informa tique en nuage du gc publie julliet 2022.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/canada-ca/TBS-OCIO-ESP/HEAD/cloud cost/Guide sur la gestion des coûts de l’informa tique en nuage du gc publie julliet 2022.pdf
--------------------------------------------------------------------------------
/GuardrailCrosswalks/README.md:
--------------------------------------------------------------------------------
1 | # GC Cloud Guardrail Crosswalk With Cloud Provider Config Checks
2 |
3 | This page is a work in progress. This is an experiment to crosswalk the GC Cloud Guardrails with the delivered configuration checks offered by Cloud Service Providers (CSPs). This should not be viewed as TBS guidance.
4 |
5 | ## Azure
6 | The Azure crosswalk can be found in the form of an [Excel spreadsheet](AzureCrosswalk.xlsx)
7 |
8 |
9 | The checks are taken, primarily, from the Azure Defender [compliance checks for FedRAMP](https://docs.microsoft.com/en-us/azure/governance/policy/samples/fedramp-moderate)
10 |
11 | ## AWS
12 | Coming next
13 |
--------------------------------------------------------------------------------
/earb-forward-agenda/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 | EARB Forward Agenda Data Tool
9 |
10 |
12 |
14 |
15 |
16 |
17 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
32 |
33 |
34 |
35 |
Français - Il s'agit d'un outil interne au groupe d'architecture d'entreprise du
36 | gouvernement du Canada. Il est fourni à des fins de référence et n'est pas pris en charge pour un usage
37 | public pour le moment. Vous pouvez accéder au programme suivant, ici.
39 |
40 |
41 |
42 |
English - This is an internal tool for the Government of Canada, Enterprise Architecture
43 | Group. It is provided for reference purpose, and is not supported for public use at this time. You can
44 | access the Forward Agenda here.
45 |
46 |
47 |
GC-EARB Forward Agenda API Tool
48 |
49 |
50 |
51 |
To use this tool, provide a valid Authorization Token, then click Create Content to produce the Forward
52 | Agenda. Then click copy content to copy the agenda to the clipboard.
7 |
8 | [1. Purpose](#purpose)
9 |
10 | [2. Context](#context)
11 |
12 | [3. Policy References](#policy_references)
13 |
14 | [4. Reference Architecture Overview](#ref_arch_overview)
15 |
16 | [5. User Technology](#user_technology)
17 |
18 | > [5.1. GC User vs GC Field User](#gc_user)
19 | >
20 | > [5.2. Portable Compute Device](#portable_compute)
21 | >
22 | > [5.3. Office 365 Account](#office_365_account)
23 | >
24 | > [5.4. GC Secure Remote Access Account](#gc_sra)
25 | >
26 | > [5.5. Telephony Services](#telephony_services)
27 | >
28 | > [5.6. Internal Credential](#internal_credential)
29 |
30 | [6. Facility Technology](#facility_technology)
31 |
32 | > [6.1. Home Office (remote)](#home_office)
33 | >
34 | > [6.2. GC Facility](#gc_facility)
35 | >
36 | > [6.2.1. Workpoints](#workpoints)
37 | >
38 | > [6.2.2. Collaboration Spaces](#collaboration_spaces)
39 | >
40 | > [6.2.3. GCSI Terminal (optional)](#gcsi_terminal)
41 | >
42 | > [6.2.4. Fixed Line Telephones (limited/optional)](#fixed_line)
43 | >
44 | > [6.2.5. Printer Devices](#printer_devices)
45 | >
46 | > [6.2.6. Fixed Compute Devices (limited/optional)](#fixed_compute)
47 |
48 | [7. Networking](#networking)
49 |
50 | > [7.1. Commercial Internet](#commercial_internet)
51 | >
52 | > [7.2. Cellular network (optional)](#cellular-network-optional)
53 | >
54 | > [7.3. GCSI (optional)](#gcsi)
55 |
56 | [8. External, Supporting, Services](#external_supporting_services)
57 |
58 | > [8.1. GC Wide Area Network (GC WAN)](#gc_wan)
59 | >
60 | > [8.2. Office 365](#office_365)
61 | >
62 | > [8.3. GC Secret Infrastructure (GCSI)](#gc_secret_infrastructure)
63 | >
64 | > [8.4. Cellular Network Provider](#cellular_network_provider)
65 |
66 | # 1. Purpose
67 |
68 | The purpose of this document is to provide guidance to departments and agencies on the technology that should be deployed to hybrid work (remote + GC offices) and further articulate the technology aspects of the [Directive on Service and Digital](https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32601).
69 |
70 | # 2. Context
71 |
72 | The pandemic has ushered in a shift in where and how GC employees and consultants work. For some, pre and post-pandemic work arrangements will not change as they are required to work on-site. For the majority or the GC's workforce, a hybrid work arrangement is not only possible, but has become a widespread practice. Supporting a hybrid work arrangement relies heavily on digital tools to support communication and collaboration. An employee is not longer expected to have a one-to-one relationship with an assigned deck in an office. Instead, an employee may work from home, GC co-working sites, GC workspace (multiple departments sharing one facility), and travelling. To support a hybrid arrangement, user technology must be:
73 |
74 | - Untethered by being connected to a wireless network, or easily disconnected and reconnected to a wired network.
75 |
76 | - Portable by being easily carried by the user between locations.
77 |
78 | The GC's collaboration space is the Office 365 cloud-based service. Users (consultants and employees) are all connecting to GC services from the internet. The general trend is data gravity is tipping towards the internet.
79 |
80 | Finally, the growing implementation of zero-trust architectures (ZTA) in technology. Amongst other things, ZTA allows for sensitive data to traverse untrusted networks.
81 |
82 | These forces require that the GC have a recognized reference architecture for its user and facilities-based technologies that supports digital, hybrid, work arrangements.
83 |
84 | # 3. Policy References
85 |
86 | The Directive on Service and Digital contains two Standards that articulate the technology users and facilities must have to support a digital workspace. This document is guidance to departments and agencies to understand how those standards should be used in the context of a reference architecture to support hybrid work arrangements.
87 |
88 | Standard on Information Technology User and Workpoint Profiles
89 |
90 | [https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32601](https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32601)
91 |
92 | Standard on Information Technology Provisions
93 |
94 | [https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32674](https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32674)
95 |
96 | # 4. Reference Architecture Overview
97 |
98 | The Hybrid Work Reference Architecture is illustrated below.
99 |
100 |
103 |
104 |
105 | # 5. User Technology
106 |
107 | User technology is any technology assigned to a user and stays with the user. This technology, ideally, is portable and untethered.
108 |
109 | ## 5.1. GC User vs GC Field User
110 |
111 | A GC User is recognized as working in one or more GC facilities or remotely from home. In contrast, the GC Field User does not work in any facility and is largely reliant on commercial cellular networks for connectivity. Aside from connectivity, the technology assigned the each type of user is similar with some possible variations.
112 |
113 | ## 5.2. Portable Compute Device
114 |
115 | GC Users will have a portable compute device. The exact specifications are determined by the department or agency, but it must, at a minimum, have:
116 |
117 | - A camera
118 |
119 | - Speakers
120 |
121 | - Microphone
122 |
123 | - Wireless network connectivity (wi-fi for GC Users and Cellular network for GC Field User)
124 |
125 | GC Field Users may have a more ruggedized compute device.
126 |
127 | ## 5.3. Office 365 Account
128 |
129 | To support conferencing/collaboration service, email, file sharing, and other office automation capabilities, each user is provided, at a minimum, an E3 Office 365 subscription (account). When a GC user leaves a department or agency, their account must be inactivated.
130 |
131 | ## 5.4. Secure Remote Access Account
132 |
133 | To provide Virtual Private Network account capabilities, each GC User is assigned a Secure Remote Access (SRA) account. This account provides the capability of a GC compute device to connect to the GC Wide Area Network over a commercial internet connection.
134 |
135 | ## 5.6. Telephony Services
136 |
137 | Currently, the following telephony technologies are available:
138 |
139 | - Fixed-line where a device is in a fixed location with a wired, traditional, carrier connection from a tele-com provider.
140 |
141 | - Smartphone with a cellular network plan and wi-fi calling capabilities must be enabled. A data plan is typically included in this offering.
142 |
143 | - Cellphones which do not have advance compute capabilities like a smartphone, but provides voice and sometimes data capabilities.
144 |
145 | - Softphones are a Microsoft Team client with a Voice over Internet Protocol (VoIP) plan.
146 |
147 | Smartphones must have wi-fi calling enabled and have the ability to join the wireless internet broadcasted in GC facilities and non-GC facilities
148 |
149 | ***NOTE:*** At the time of writing, smartphones are the preferred telephony technology with fixed-line phones being used in limited cases. A proposal is currently under consideration to make softphones (MS Teams client + VoIP plan) the preferred telephony technology.
150 |
151 | ## 5.7. Internal Credential
152 |
153 | GC Users will be issued a GC credential to be used for authentication purposes.
154 |
155 | # 6. Facility Technology
156 |
157 | Facilities technology is technology that must be present in a work location to support user technology.
158 |
159 | ## 6.1. Home Office (remote)
160 |
161 | The home is not a GC managed facility, but one that still requires technical capabilities for the employee. A commercial internet connection from a tele-com provider or, more recently, low earth orbit satellite provider, that can support streaming video, is a requirement.
162 |
163 | Home offices may also receive a cellular network broadcast to support smartphone voice and data capabilities.
164 |
165 | ## 6.2. GC Facility
166 |
167 | In many ways, from a technical point of view, a GC facility is a large-scale home office with the exception of optional GC Secret Infrastructure (GCSI) network and terminal technology.
168 |
169 | ### 6.2.1. Workpoints
170 |
171 | Workpoints are for individual work and are typically instantiated as a desk or cubicle. In a hybrid work environment no technology should be fixed to the workpoint except in limited cases. Limited case may include, but not limited to:
172 |
173 | - Accommodation needs
174 |
175 | - Operational needs
176 |
177 | - Business continuity (e.g. a limited number of fixed telephone devices deployed in a facility as a back-up for cellphone or internet interruption)
178 |
179 | ### 6.2.2. Collaboration Spaces
180 |
181 | Collaboration spaces, including traditional, conference rooms, will benefit from systems that allow multiple users within a space to collaborate with other users online. Collaboration spaces can often have dedicated devices and equipment to support multiple users collaborating with other users online. Those devices and equipment must be compatible with Microsoft Teams.
182 |
183 | ### 6.2.3. GCSI Terminal (optional)
184 |
185 | For national security scenarios, where required, the GC Secret Infrastructure (GCSI) will be deployed into GC facilities. The decision to deploy GCSI in a GC facility is driven by the tenants' operational requirements.
186 |
187 | ### 6.2.4. Fixed Line Telephones (limited/optional)
188 |
189 | For business continuity, operational need, or accommodating accessibility needs, fixed lines may be deployed in limited numbers in a GC facility.
190 |
191 | ### 6.2.5. Printer Devices
192 |
193 | Print devices are deployed on a limited basis throughout a GC facility.
194 |
195 | ### 6.2.6. Fixed Compute Devices (limited/optional)
196 |
197 | Fixed compute (desktops) are used in limited circumstances where
198 |
199 | - compute requirements exceed those available on a portable compute device
200 |
201 | - The fixed compute device supports static equipment such as for science or other connected devices
202 |
203 | Since these devices are not portable and forces the user to be in a GC facility to be used, fixed compute should be used only when necessary. Portable compute remains the preferred choice.
204 |
205 | # 7. Networking
206 |
207 | This section describes the network options available to facilities and, by extension, the user's technology when in those facilities. With the exception of GCSI, both home and GC facilities have the same network options available.
208 |
209 | ## 7.1. Commercial Internet
210 |
211 | With GC Secure Remote Access having been scaled to support the pandemic, there is no longer a need to bring the GC Wide Area Network (WAN) into GC facilities. Commercially available internet from Internet Service Providers is sufficient. In this way, from a technology perspective, the GC facility can be viewed as a scaled up home office. Using commercially available internet as the means to connect the user to GC WAN, through SRA, and internet services brings the GC closer to a full zero-trust deployment of services. This network architecture will support use cases categorised as non-national security (ie unclassified, Protected A, B, and C).
212 |
213 | Commercial internet must be, to the maximum extent possible, deployed wirelessly and broadcast through-out the building. At a minimum, two SSIDs should be available. The first will restrict connectivity to GC devices and the second SSID will be for guest devices and be appropriately throttled. GC devices include compute devices, conferencing/collaboration devices, printers, and smartphones to support wi-fi calling.
214 |
215 | ## 7.2. Cellular network (optional)
216 |
217 | Commercial cellular network may be broadcast from outside of the GC facility. Pico cells or in-facility cellular networks will no longer be deployed. In cases where cellular network performance is insufficient to support smartphones, wi-fi calling will be sufficient for supporting smartphones within GC facilities.
218 |
219 | ## 7.3. GCSI (optional)
220 |
221 | For national security scenarios, where required, the GC Secret Infrastructure (GCSI) will be deployed into GC facilities. The decision to deploy GCSI in a GC facility is driven by the tenants' operational requirements.
222 |
223 | # 8. External, Supporting, Services
224 |
225 | ## 8.1. GC Wide Area Network (GC WAN)
226 |
227 | The GC WAN is the location of applications hosted within GC data centres. It is also the gateway for the GC SRA service. Connections to the GC WAN are over commercial internet with the addition of SRA (VPN).
228 |
229 | ## 8.2. Office 365
230 |
231 | Supporting Office 365 accounts is the Office 365, public cloud-based, service. Office 365 is accessed over commercial internet using inverse split tunneling and TLS encryption to project all communication between the users' devices and the Office 365 service.
232 |
233 | ## 8.3. GC Secret Infrastructure (GCSI)
234 |
235 | The GCSI is the location of secret applications and can only be accessed by GCSI terminals.
236 |
237 | ## 8.4. Internet Service Provider (ISP)
238 |
239 | An ISP is a commercial entity, such as a tele-com or low earth orbit satellite provider, who provides access to the internet.
240 |
241 | ## 8.5. Cellular Network Provider
242 |
243 | A cellular network provider is a commercial entity, such as a tele-com, who broadcasts a cellular signal.
244 |
245 |
--------------------------------------------------------------------------------
/azure-pipelines-past-sessions.yml:
--------------------------------------------------------------------------------
1 | schedules:
2 | - cron: '0 */6 * * *'
3 | displayName: Run every 6 hours
4 | branches:
5 | include:
6 | - master
7 | always: true
8 |
9 | # A pipeline with no CI trigger
10 | trigger: none
11 |
12 | pool:
13 | vmImage: windows-latest
14 |
15 | steps:
16 | - task: PowerShell@2
17 | env:
18 | # Create bot password from https://wiki.gccollab.ca/Special:BotPasswords
19 | WIKI_USER: $(WIKI_USER)
20 | WIKI_PASSWORD: $(WIKI_PASSWORD)
21 | ADO_TOKEN: $(ADO_TOKEN)
22 | inputs:
23 | targetType: 'inline'
24 | script: |
25 | $wikiTitle = $env:WIKI_TITLE
26 | $username = $env:WIKI_USER
27 | $password = $env:WIKI_PASSWORD
28 | $pastSessionQuery = 'https://analytics.dev.azure.com/TBS-OCIO-ESP/_odata/v1.0/WorkItems?$select=Title,%20State,%20Custom_Department,%20Custom_FrenchTitle,%20WorkItemType,%20BacklogPriority&$expand=Iteration($select=IterationPath),%20Links($select=TargetWorkItem;%20$filter=(TargetWorkItem/Project/ProjectName%20eq%20%27gc-earb%27%20AND%20((TargetWorkItem/WorkItemType%20ne%20%27%27%20AND%20TargetWorkItem/State%20ne%20%27Cancelled%27%20AND%20TargetWorkItem/Title%20ne%20%27Opening%20Remarks%27%20AND%20TargetWorkItem/Title%20ne%20%27Closing%20Remarks%27)%20OR%20(TargetWorkItem/State%20eq%20%27Cancelled%27%20AND%20TargetWorkItem/Title%20eq%20%27Opening%20Remarks%27)))%20and%20(LinkTypeReferenceName%20eq%20%27System.LinkTypes.Hierarchy-Forward%27);%20$expand=TargetWorkItem($select=Title,%20State,%20Custom_Department,%20Custom_FrenchTitle,%20WorkItemType,%20BacklogPriority;%20$expand=Iteration($select=IterationPath)))&$filter=(Project/ProjectName%20eq%20%27gc-earb%27%20AND%20WorkItemType%20eq%20%27Meeting%27%20AND%20(State%20eq%20%27Done%27%20or%20State%20eq%20%27Cancelled%27))%20and%20Links/any(l:%20(l/TargetWorkItem/Project/ProjectName%20eq%20%27gc-earb%27%20AND%20((l/TargetWorkItem/WorkItemType%20ne%20%27%27%20AND%20l/TargetWorkItem/State%20ne%20%27Cancelled%27%20AND%20l/TargetWorkItem/Title%20ne%20%27Opening%20Remarks%27%20AND%20l/TargetWorkItem/Title%20ne%20%27Closing%20Remarks%27)%20OR%20(l/TargetWorkItem/State%20eq%20%27Cancelled%27%20AND%20l/TargetWorkItem/Title%20eq%20%27Opening%20Remarks%27)))%20and%20(l/LinkTypeReferenceName%20eq%20%27System.LinkTypes.Hierarchy-Forward%27))&$orderby=Iteration/IterationPath%20desc,%20BacklogPriority%20asc,%20WorkItemId%20asc';
29 |
30 | function Get-QueryResultsTable($token, $odataQuery)
31 | {
32 | if ($null -eq $token)
33 | {
34 | throw('Missing token value')
35 | }
36 | if ($null -eq $odataQuery)
37 | {
38 | throw('Missing OData query')
39 | }
40 | $authHeader = @{ 'Authorization' = 'Basic ' + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":" + $token)) }
41 | $result = Invoke-RestMethod -Method Get -Uri $odataQuery -Headers $authHeader
42 | $meetings = $result.value
43 | $wikicontent = "{{OCIO_GCEARB_Header}}`n`n"
44 | $englishcontent = "@en|__NOTOC__`n"
45 | $frenchcontent = "@fr|__NOTOC__`n"
46 | $frCulture = New-Object system.globalization.cultureinfo('fr-CA')
47 |
48 | # GCConnex Link
49 | $englishcontent += "
Records of discussions and GC EARB presentations are posted on the: [https://gcconnex.gc.ca/groups/profile/29755185/gc-enterprise-architecture-review-board-comite-dexamen-de-larchitecture-dentreprise-du-gc?language=en GC Enterprise Architecture Review Board GCconnex page]'''.'''
"
50 | $frenchcontent += "
Les comptes rendus des discussions et des présentations du CEAI GC sont affichés sur: [https://gcconnex.gc.ca/groups/profile/29755185/gc-enterprise-architecture-review-board-comite-dexamen-de-larchitecture-dentreprise-du-gc?language=fr Comité d’examen de l’architecture intégrée du GC]'''.'''
Metrics for Government of Canada Technology Consumption
2 |
3 |
4 | | **Category** | **Metric** | **Details** | **Metric Owner** |
5 | |---------------------------------------------------|----------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------|----------------------------------------------|
6 | | Telephony | Per capita mobile devices | Number of devices (mobile phones, connected tablets, or other cellular devices) | Shared Services Canada (SSC) |
7 | | | Per capita phone plans | Includes cellular and fixed plans | Shared Services Canada |
8 | | | Total fixed lines per department, broken down by type – Centrex, Private Branch Exchange (PBX), Voice Over IP (VOIP) | | Shared Services Canada |
9 | | Software and Hardware Provisioning Services | Number of provisioned software licences per software selection | For software sold and distributed through SSC procurement processes. | Shared Services Canada |
10 | | Email Services | Number of email accounts | Grouped by 035 and legacy | Shared Services Canada (legacy environments) |
11 | | | Average email box size in GB | Only for non-legacy environments. Legacy environments have fixed email box size of 2 GB | Shared Services Canada (O365) |
12 | | Collaboration Services | Collaboration software account plans | | Departments (O365) |
13 | | Audio-Conferencing Services | Audio-conference account plans | | Shared Services Canada |
14 | | Video-Conferencing Services | Video-conference account plans | | Shared Services Canada |
15 | | | Video-conference endpoints | | Shared Services Canada |
16 | | Cloud Brokering Services | Number of cloud brokering requests | | Shared Services Canada |
17 | | Mid-Range Services | Number of Operating System Instances (OSI) | By type and version | Shared Services Canada |
18 | | Database and Storage Services | Terabytes (TB) of storage | | Shared Services Canada |
19 | | High Performance Computing (HPC) Services | Terabytes (TB) of storage | | Shared Services Canada |
20 | | | Computing Core Hours | | Shared Services Canada |
21 | | | Visualization Licences | | Shared Services Canada |
22 | | Mainframe Services | Million Instructions per Second (MIPS) | | Shared Services Canada |
23 | | | Terabytes (TB) of storage | | Shared Services Canada |
24 | | Application Hosting | Number of applications supported | | Shared Services Canada |
25 | | Network Services | Peak network volume per user in megabits per second (Mbps) | Tested at all network points (current and historical) | Shared Services Canada |
26 | | | Number of network connections | | Shared Services Canada |
27 | | GC Wireless Network Services | Wireless access points | | Shared Services Canada |
28 | | | Signal strength for wireless access points in decibel-milliwatts (dBm) | | Shared Services Canada |
29 | | Cabling Services | Network access points | Also known as drops or network ports | Shared Services Canada |
30 | | Government of Canada Secret Infrastructure (GCSI) | GCSI accounts | | Shared Services Canada |
31 | | | Average network bandwidth per user in megabits per second (Mbps) | | Shared Services Canada |
32 | | | Number of GCSI terminals | | Shared Services Canada |
33 | | Internal Credential Management (ICM) Services | Number of accounts | | Shared Services Canada |
34 | | Secure Remote Access (SRA) Services | Number of concurrent user accounts | Usage and performance | Shared Services Canada |
35 | | | Number of Virtual Private Network (VPN) accounts | | Shared Services Canada |
36 | | External Credential Management (ECM) Services | Number of credentials | | Shared Services Canada |
37 | | Satellite Services | Number of fixed satellite sites | | Shared Services Canada |
38 | | | Number of mobile satellite devices | | Shared Services Canada |
39 | | Bulk Print Services | Number of pages printed | | Shared Services Canada |
40 | | Contact Centre Services | Concurrent number of agents per month | | Shared Services Canada |
41 | | | Peak agent usage per month | | Shared Services Canada |
42 |
43 |
Mesures de l’utilisation de la technologie au gouvernement du Canada
44 |
45 | | **Catégorie** | **Unité de mesure** | **Détails** | **Responsable de la mesure** |
46 | |----------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|---------------------------------------------|
47 | | Téléphonie | Appareils mobiles par employé. | Nombre d’appareils (téléphones mobiles, tablettes connectées ou autres appareils cellulaires.) | Services partagés Canada (SPC) |
48 | | | Forfaits téléphoniques par employé. | Comprennent les forfaits de téléphonie cellulaire et fixe. | Services partagés Canada |
49 | | | Total des lignes fixes par ministère, réparti par type – Centrex, autocommutateur privé (PBX), voix par protocole IP (VoIP). | | Services partagés Canada |
50 | | Services d’approvisionnement en logiciels et en matériel | Nombre de licences accordées par sélection de logiciels. | Pour les logiciels vendus et distribués dans le cadre des processus d’approvisionnement de SPC. | Services partagés Canada |
51 | | Services de courrier électronique | Nombre de comptes de courrier électronique. | Regroupés par 035 et anciens systèmes. | Services partagés Canada (anciens systèmes) |
52 | | | Taille moyenne des boîtes de messagerie en Go. | Seulement pour les systèmes non anciens. Les anciens systèmes ont une taille de boîte de messagerie fixe de 2 Go. | Services partagés Canada (O365) |
53 | | Services de collaboration | Forfaits de comptes de logiciel de collaboration. | | Ministères (O365) |
54 | | Services de conférences téléphoniques | Forfaits de comptes des conférences téléphoniques. | | Services partagés Canada |
55 | | Services de vidéoconférence | Forfaits de comptes des vidéoconférences. | | Services partagés Canada |
56 | | | Points finaux de la vidéoconférence. | | Services partagés Canada |
57 | | Services de courtage en infonuagique | Nombre de demandes de courtage en matière d’informatique en nuage. | | Services partagés Canada |
58 | | Services de milieu de gamme | Nombre d’instances de système d’exploitation (ISE). | Par type et version | Services partagés Canada |
59 | | Services de base de données et de stockage | Téraoctets (To) de stockage. | | Services partagés Canada |
60 | | Services de calculs de haute performance (CHP) | Téraoctets (To) de stockage. | | Services partagés Canada |
61 | | | Heures normales de calculs. | | Services partagés Canada |
62 | | | Licences de visualisation. | | Services partagés Canada |
63 | | Services de l’ordinateur central | Million d’instructions par seconde (MIPS). | | Services partagés Canada |
64 | | | Téraoctets (To) de stockage. | | Services partagés Canada |
65 | | Hébergement d’applications | Nombre d’applications prises en charge. | | Services partagés Canada |
66 | | Services de réseau | Volume maximum du réseau par utilisateur en mégaoctets par seconde (Mo/s). | Testé à tous les points du réseau (actuels et historiques). | Services partagés Canada |
67 | | | Nombre de connexions au réseau. | | Services partagés Canada |
68 | | Services de réseau sans fil au GC | Points d’accès sans fil. | | Services partagés Canada |
69 | | | Force du signal pour les points d’accès sans fil en décibels par rapport à 1 mW (dBm). | | Services partagés Canada |
70 | | Services de câblage | Points d’accès au réseau. | Aussi appelés points de raccordement ou ports de réseau. | Services partagés Canada |
71 | | Infrastructure secrète du gouvernement du Canada (ISGC) | Comptes ISGC. | | Services partagés Canada |
72 | | | Bande passante moyenne de réseau par utilisateur en mégaoctets par seconde (Mo/s). | | Services partagés Canada |
73 | | | Nombre de terminaux ISGC. | | Services partagés Canada |
74 | | Services de gestion des justificatifs internes (GJI) | Nombre de comptes. | | Services partagés Canada |
75 | | Services d’accès à distance sécurisé (ADS) | Nombre de comptes utilisateurs concomitants. | Utilisation et rendement. | Services partagés Canada |
76 | | | Nombre de comptes de réseau privé virtuel (RPV). | | Services partagés Canada |
77 | | Services de gestion des justificatifs externes (GJE) | Nombre de justificatifs. | | Services partagés Canada |
78 | | Services par satellite | Nombre de sites fixes d’accès aux satellites. | | Services partagés Canada |
79 | | | Nombre d’appareils mobiles ayant accès aux satellites. | | Services partagés Canada |
80 | | Services d’impression en bloc | Nombre de pages imprimées. | | Services partagés Canada |
81 | | Services des centres de contact | Nombre concurrent d’agents par mois. | | Services partagés Canada |
82 | | | Utilisation maximale d’agents par mois. | | Services partagés Canada |
83 |
--------------------------------------------------------------------------------
/gc_cloud_cost_management_guidance/readme.md:
--------------------------------------------------------------------------------
1 |
2 | Original PDFs with images can be found here:
3 |
4 | * [English](https://github.com/canada-ca/TBS-OCIO-ESP/blob/master/cloud%20cost/GC%20Cloud%20Cost%20Management%20Playbook%20Published%20July%202022.pdf)
5 | * [francais](https://github.com/canada-ca/TBS-OCIO-ESP/blob/master/cloud%20cost/Guide%20sur%20la%20gestion%20des%20cou%CC%82ts%20de%20l%E2%80%99informa%20tique%20en%20nuage%20du%20gc%20publie%20julliet%202022.pdf)
6 |
7 | [(francais)](#francais)
8 |
9 | GC Cloud Cost Management Playbook
10 | =================================
11 |
12 | # Purpose
13 |
14 | The purpose of this document is to:
15 |
16 | - Support Government of Canada organizations adoption of cloud while applying financial due diligence while maintaining agility
17 |
18 | - Provide a set of practices to maintain cost management in the cloud without negatively impacting agility and other cloud attributes
19 |
20 | - Providing stakeholders with an overview of cloud cost management including financial & procurement officers
21 |
22 | # Context
23 |
24 | Cloud computing provides on-demand, pay-as-you-go models for computing, storage, network, platforms, and business solutions. Cloud costs are fluid and directly related to the unit price of the resources multiplied by usage (cost = price x usage). This represents a fundamental shift from traditional, fixed, IT consumption models where the primary cost is associated with the purchase of hardware or licensing of software. In a cloud model, cost is a direct input into application architecture. Cloud spending is much more dynamic than traditional IT models as usage changes result in immediate cost changes. The feedback loop between usage and cost is immediate. Traditional spend controls rely heavily on process gates with people-intensive oversight. These traditional practices are a poor fit for a cloud environment as they can negatively impact the agility delivery teams desire when using cloud and lead to disrupted business value. Finance and procurement officers are not gatekeepers to cloud spend, but support delivery teams in establishing budgets for the delivery of their products. Delivery teams are directly responsible for cloud costs and must be prepared to track, analyze, and optimize the costs associated with their products and the usage of those products. These practices are often known as 'FinOps'. FinOps is a set of practices that encourage management & optimization of cloud spending without disrupting the agility and speed of cloud delivery.
25 |
26 | # FinOps
27 |
28 | Often the term 'FinOps' is applied to cloud cost management. FinOps is a portmanteau of Financial Operations. FinOps is supported by a community lead [FinOps Foundation]. The foundation and technology consultancies have published a library of information on this topic. This guidance should not be read in isolation of that library of material. FinOps is an evolving area as cloud itself evolves.
29 |
30 | # Traditional Models Contrasted with Cloud
31 |
32 | One can thinking about the shifting from traditional IT models to a cloud model using the analogy of shifting from digging and maintaining your own well vs connecting to the municipal water supply. Both deliver water, but each has a different model behind it. With a well, you must take on the responsibility of purchasing equipment, engineering, and building the well, and be responsible for maintaining the pumps and quality of the water. With a municipal water supply, you simply pay a monthly metered water consumption charge, and you are abstracted from the assets required to deliver the water. This, in many ways, is the shift that cloud has introduced. Traditional IT models, like digging wells, is a capital and asset intense delivery model. Cloud, like municipal water supply, turns the supply into a commoditized service.
33 |
34 | The table below assumes that the pay-as-you-go (PAYG) model for cloud has been maintained. It should be noted that depending upon how your organization structures its agreement with providers, portions of this table may not apply. For example, if through a contract the consumer pays for years of services up-front, portions of this table will not apply. Furthermore, this table's scope are the cloud services themselves, and does not include capital costs for implementing the services or extending/building within these platforms.
35 |
36 |
37 |
38 | | Traditional IT Models | Cloud Models |
39 | |------------------------|---------------|
40 | |Traditional IT relies on a Capital Expense model (CapEX) where goods (software, hardware, facilities) are bought, maintained as an asset for a determined life span.|Cloud service are an Operational Expense, much like a utility such as electricity or municipal water, the degree of usage drives cost.|
41 | |The degree to which an asset (hardware and software) is consumed has no material impact on cost. Once a purchase is made, the costs are sunk into the asset and there are no mechanisms to optimize those costs after purchase.|Consuming cloud resources results in costs. Turning off the usage of a service results in cost avoidance.|
42 | |Traditional investments are typically periodic associated with the replacement of aging assets. |Cloud costs are in perpetuity until the service is turned off.|
43 | |Traditional models are primarily fixed costs.|Cloud costs are variable.|
44 | |Traditional costs reporting is periodic, often annual as costs are largely fixed.||Cloud costs are real-time as they are variable|
45 | |Traditional models have straight forward cost driver. |Cloud bills are complex often comprised of micro-transactions tracking each usage.|
46 | |Purchasing of capital assets are centrally gated by procurement and financial organizations.| Cloud purchases are decentralized being made by delivery teams delivering digital products with the cloud.|
47 |
48 |
49 |
50 |
51 | # Optimizing Cloud Costs
52 |
53 | When contrasted against traditional IT models, cloud allows for more options for shaping spend. Levers in the form of optimization decisions can be taken to reduce waste and right-size consumption. Conversely, decisions can be made to spend more to get greater speed and scaling. Optimization choices can be plotted on a simple quadrant to illustrate the trade offs between time and cost as seen in figure 2. Optimization is focused on reducing waste and shaping spend. Continuous optimization may not lead to reductions in overall cloud spent over the long-term. Often, organizations continue to grow their cloud usage with time in the form of new services, new data, and new user experiences. The increased digitization of an organization's business will, over time, result in an overall increase in cloud spend. Optimization can help ensure that spend is well governed and not resulting in needless waste.
54 |
55 | ## Feedback Loops
56 |
57 | A key attribute of how costs are managed in the cloud depends upon the real-time feedback loop between using cloud and cloud costs. This simple feedback look drives financial behaviours that can lead to optimizing cloud usage to reduce needless spending.
58 |
59 | ## Business Value, Not Lowest Cost
60 |
61 | The goal of cost management is not to drive to the lowest cost but instead:
62 |
63 | 1. Optimize unnecessary waste
64 |
65 | 2. Delivery business value
66 |
67 | Driving to the lowest cost possible can impact business value. Delivery teams and business owners may be willing to trade higher costs for quicker delivery. For example, a delivery team may decide to deploy an architecture that is not optimized because a simpler architecture may lead to faster delivery of a solution. The trade-offs between potential savings and the effort required to achieve those savings is illustrated below. Another example is prioritizing the launch of a new feature may be deemed higher that refactoring a piece of code that could lead to lower cloud costs. Therefore, opportunities for cost optimization become part of a product's feature backlog like. Opportunities to optimize a product for cost must be prioritized with other backlog items like new user experiences, new business rules, and other feature requests.
68 |
69 | Managing cloud costs is not about driving to the lowest cost, but instead applying financial due diligence while driving business value for the organization.
70 |
71 | # Plays
72 |
73 | This document contains plays that organizations should undertake to exercise due diligence over cloud spend. This is not a comprehensive set of practices, but instead represent suggested, minimum practices.
74 |
75 | |No. |Play|
76 | |-------------|----|
77 | |01 |Accountability|
78 | |02 |Visibility & Transparency|
79 | |03 |Cost attribution|
80 | |04 |Budgeting|
81 | |05 |Service Policies & Alerting|
82 | |06 |Optimization|
83 | |07 |Cost remediation|
84 | |08 |Governance|
85 | |09 |Set business metrics|
86 |
87 |
88 | # 01 Accountability
89 |
90 |
91 |
92 | ## Objective
93 |
94 | Delivery teams[^1] must be ready to assume cost management and optimization responsibilities. The implications of architectural designs and provisioning choices need to be understood by delivery team members.
95 |
96 | ## Description of Activities
97 |
98 | - Ensure delivery teams are aware of the impact of their consumption, configuration, and architectural choices have on costs
99 |
100 | - Consider setting a cloud financial management (FinOps) training requirement for all delivery team members
101 |
102 | - Ensure the basic concepts of FinOps practices and the guardrails listen in this document need to be understood by delivery team members
103 |
104 | - Use the GC FinOps RACI (link required) as a template to tailor to your organization's roles
105 |
106 | - Determine a centralized role within your organization who will manage cloud spend data and decisions with your organization's governance. This does not need to be a dedicated role, but part of a Cloud Centre of Expertise's responsibilities.
107 |
108 | - Determine the role of financial officers in your organization's FinOps practices
109 |
110 | ## References
111 |
112 | -
113 |
114 | -
115 |
116 |
117 |
118 | # 02 Visibility & Transparency
119 |
120 |
121 | ## Objective
122 |
123 | Empower delivery teams with self-service access to cost reports. Delivery teams must have complete visibility into the services and usage that is driving cloud service costs associated with the delivery of their products. Be transparent with all stakeholders on cloud costs.
124 |
125 | ## Description of Activities
126 |
127 | - Provide reports and dashboards on past, current, and forecasted cloud spend to stakeholders
128 |
129 | - Provide a standardized cost reports to all delivery teams, but allow delivery teams to tailor those reports to their needs
130 |
131 | - Provide reports in such a way that a delivery team can isolate costs associated with the delivery of their products
132 |
133 | - Maintain visibility over all cloud accounts and cloud services. If your organization uses multiple cloud providers, visibility over all providers and accounts will need to be maintained.
134 |
135 | - Provide all stakeholders with transparency on cloud costs
136 |
137 | - Determine how high in the organization cloud spend data should reach. For example, does the CIO or CFO have an interest in monthly reports?
138 |
139 | ## References
140 |
141 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
142 |
143 | ## Automation
144 |
145 | - Check to see that the billing dashboard or API is being invoked on a periodic basis
146 |
147 | - Check that the developer and architect roles also have access to the billing console and APIs
148 |
149 | # 03 Cost Attribution
150 |
151 |
152 | ## Objective
153 |
154 | Establish a structure for tagging cloud resources and attributing costs back to the lines of business and cost centres funding those costs.
155 |
156 | ## Description of Activities
157 |
158 | - Document and approve a standardized set of tags to identity how the cost of resources is attributed back to applications and lines of business for billing proposes
159 |
160 | - Document and approved a resource hierarchy structure or groupings that support attribution of costs back to lines of business for billing purposes
161 |
162 | - Use resource tagging and structures to act as reporting dimensions so that costs can be attributed back to lines of businesses and fund centres that fund the delivery of products
163 |
164 | - Search and remediate any untagged resources or resources that exist outside of cost allocation structures
165 |
166 | - Maintain the hygiene of resource:
167 |
168 | - Identify and remediate orphaned resources
169 |
170 | - Use automation through the implementation of service policies to enforce tagging hygiene where possible.
171 |
172 | - For common cloud platform resources that cannot be attributed to a single product or line of business:
173 |
174 | - Determine a methodology for attributing common costs, for example:
175 |
176 | - Proportional; based upon relative percentage of direct costs (e.g., 10% of direct cloud spend)
177 |
178 | - Even split; split total amount evenly across products (e.g., common costs/number of products)
179 |
180 | - Fixed; like even split, but with a co-efficient to weigh the proportion allocated to each product. Total of all coefficients must add up to 1. (e.g., 0.3 of common costs)
181 |
182 | - Determine a show-back/charge-back methodology for making common costs visible to each product
183 |
184 | ## References
185 |
186 | -
187 |
188 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
189 |
190 | ## Automation
191 |
192 | - Check for resources that do not have approved cost allocation tags
193 |
194 | - Use service policies to enforce mandatory cost allocation tags
195 |
196 | # 04 Budgeting
197 |
198 |
199 |
200 | ## Objectives
201 |
202 | Delivery teams establish product budgets in collaboration with financial officers and undertake activities to track actual costs against forecasts.
203 |
204 | ## Description of Activities
205 |
206 | - Delivery team will work with financial officers to establish a budget for their product based upon estimated cloud hosting costs
207 |
208 | - Budgets should be broken down by billing period. Alerting should be implemented to notify delivery teams when a pre-determined percentage of the monthly forecasted budget is spent,
209 |
210 | - Delivery teams should report actuals against forecasts to determine if the 'burn rate' is within forecast.
211 |
212 | - Governance should be documented to include process and criteria for increasing budgets.
213 |
214 | - Governance of budget should allow for unplanned usage and costs, but also take corrective action to help delivery teams with repetitive unplanned spend.
215 |
216 | ## References
217 |
218 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
219 |
220 | - https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/
221 |
222 | -
223 |
224 | ## Automation
225 |
226 | - Check that the cloud service providers' features for setting and alerting on budgets have been configured
227 |
228 | # 05 Policy & Alerting
229 |
230 |
231 |
232 | ## Objectives
233 |
234 | Use alerts to provide early warning when key financial milestones are met, such as percentage spend of total budget. Use service policies to enforce key financial guardrails such as adherence to tagging standards.
235 |
236 | ## Description
237 |
238 | - Use cloud platforms' ability to alert users of financial events as a method of automating governance activities
239 |
240 | - Use service policies to enforce adherence to key financial guardrails such as tagging and automating turning off services, in particular for test and development environments. Financial guardrails differ from the GC Cloud Guardrails as they are department specific and focused on financial governance.
241 |
242 | ## References
243 |
244 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
245 |
246 | -
247 |
248 | -
249 |
250 | -
251 |
252 | ## Automation
253 |
254 | - Set alerts for accounts or resource groups based to notify delivery team members when 25%, 50%, and 75% (or whatever values best suit your context) of the team's total budget has been consumed
255 |
256 | - Set alerts for excessive percent changes in costs occurring in a short period of time
257 |
258 |
259 |
260 | # 06 Optimization
261 |
262 |
263 | ## Objectives
264 |
265 | Delivery teams should continuously analyze opportunities for optimizing service usage and architectures for cost efficiencies. Centralized FinOps teams can discover optimization opportunities to help delivery teams make optimization decisions.
266 |
267 | ## Description of Activities
268 |
269 | - Delivery teams will review cost and billing reports for possible optimization opportunities and waste
270 |
271 | - Determine the benefit verses cost of implementing optimization strategies
272 |
273 | - Opportunities to optimize architectures and usage should be added to the product's feature backlog to be prioritized along-side user feature requests and technical debt remediation. The goal is not the cheapest solution at all cost. A higher cost may be tolerated if greater deliver speed can be achieved.
274 |
275 | - Identify possible sources of waste such as resources and resources with low usage rates
276 |
277 | - Right-size resources, such a virtual-machines, by analyzing performance metrics. Move to smaller instances when possible.
278 |
279 | - Use cloud providers' cost optimization services to review recommendations and decide whether to act upon them
280 |
281 | - Rely on horizontal scaling to increase resources during peak periods.
282 |
283 | - Align capacity and demand using elasticity of horizontal and vertical scaling
284 |
285 | - Turn off resources not used outside of core hours such as development and testing environments.
286 |
287 | - Analyze usage patterns to identify opportunity to migrate to reserved instances to achieve cost efficiencies
288 |
289 | - Use service with greater ability to reduce pay-per-use costs. For example, moving from virtual machines to serverless platforms will provide greater cost granularity, but also consider the cost of refactoring may nullify those cost efficiencies gained.
290 |
291 | ## References
292 |
293 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
294 |
295 | -
296 |
297 | - Maximize Business Value with Cloud FinOps, Google Cloud, https://services.google.com/fh/files/blogs/cloud_finops_paper.pdf
298 |
299 | ## Automation
300 |
301 | - Report on the number of features requests in product backlogs are related to cost optimization.
302 |
303 | - Automate the periodic decommissioning of resources for development and testing environments outside of hours they are being used, for example, core hours.
304 |
305 | - Report on the number of compute instance and storage provisioned and trends over time.
306 |
307 | # 07 Remediation
308 |
309 |
310 | ## Objectives
311 |
312 | When cloud costs grow beyond forecasts, implement an action plan to analyze current usage and reduce waste.
313 |
314 | ## Description of Activities
315 |
316 | When unplanned spend grows, implement a plan to remediate spending growth:
317 |
318 | - Report on unexpected cost growth to governance
319 |
320 | - Present an action plan to governance for addressing unexpected cost growth
321 |
322 | - Obtain authority from governance to execute on an action plan to remediate unexpected cost growth
323 |
324 | - Bring together implicated stakeholders to form a tiger team
325 |
326 | - Hold blameless retrospectives as a method of learning from accidental cost overruns with the intent to improve future practices rather than focus on assigning blame
327 |
328 | - Perform basic analysis. Determine the source of unplanned spend increases
329 |
330 | - Trace back spend growth to the source business activities
331 |
332 | - Set achievable targets for targets for spend reduction. Look for opportunities to reduce waste and optimize usage
333 |
334 | - Implement spend reduction activities
335 |
336 | ## References
337 |
338 | - Cloud Cost Optimization, Gartner, Mike Brown
339 |
340 | - Maximize Business Value with Cloud FinOps, Google Cloud,
341 |
342 | -
343 |
344 | # 08 Governance
345 |
346 |
347 | ## Objectives
348 |
349 | Design and implement a governance to review and act upon cloud cost analysis
350 |
351 | ## Description of Activities
352 |
353 | - Encourage cloud cost transparency through reporting, including:
354 |
355 | - Costs by provider and by product
356 |
357 | - Shared costs
358 |
359 | - Spend against budgets and forecasts
360 |
361 | - Trends over time
362 |
363 | - Top and low performing delivery teams/products in terms of cost optimization
364 |
365 | - Create processes for monitoring and taking corrective action, but without impacting the speed of delivery and agility of cloud
366 |
367 | - Decide on financial guardrails and alerting all delivery teams and products must adhere to
368 |
369 | - Cost governance does not require a dedicated governance vertical, but may be integrated into other governance activities such as performance, architecture, and security
370 |
371 | - Document the roles and responsibilities associated with cloud cost management
372 |
373 | - Favor guardrails over gates for enforcing policy
374 |
375 | ## References
376 |
377 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
378 |
379 | -
380 |
381 | # 09 Business Metrics
382 |
383 |
384 | ## Objectives
385 |
386 | Increased digitization of services and automation will drive up cloud costs over time that no amount of optimization efforts will be able to reverse. Business owners need to be explained cloud costs in terms of the business being delivered using cloud services. Delivery teams must be able to report on cloud costs in the context of business metrics. The unit economics, i.e., the cost per unit, must be calculated and reported.
387 |
388 | ## Description of Activities
389 |
390 | - Collaborate with business owners to understand their digital service deliver metrics (e.g., number of inquiries, wait times, number of transactions, speed of transactions, timeliness of transactions, total value of transactions, cost effectiveness, etc\...)
391 |
392 | - Report on cloud costs in terms of digital service delivery metrics (e.g., the average cost of serving an inquiry is X dollars)
393 |
394 | - Express technology investments in terms of service deliver metrics improvements (e.g., increased investment will result in increased ability to serve more inquiries)
395 |
396 | - Report on cost and digital service delivery metrics trends over time
397 |
398 | ## References
399 |
400 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
401 |
402 | -
403 |
404 | # Cases Studies
405 |
406 | ## Treasury Board Secretariat -- Optimization with Reserved Instances
407 |
408 | Treasury Board Secretariat migrated its entire portfolio of 120 plus applications to the cloud in 2020. In that time they have gain considerable experience with optimizing their cloud usage. Moving to Reserved Instances was one way TBS optimized its use of Virtual Machines. By lock-in to a three-year purchase of VMs, a 60%, or greater, savings was achieved over pay-as-you-go models (PAYG). TBS has calculated, that in most circumstances, the break even point of a reserved instance is 15 months. This means that even if the VM is only used for 15 months of the 36 total purchase period, cost savings occur over a PAYG model. For TBS, who automated the scheduled shut-down and start-up of development and test environments to save money, moving to RIs has achieved greater cost savings than scheduling and with lower complexity.
409 |
410 | Next to migrating to reserved instances, TBS has also found setting and executing log retention periods are a considerable source of savings. Setting a retention policy for logs and then periodically cleaning up those logs that have exceeded the retention policy from block storage and PaaS yields cost avoidance.
411 |
412 | ## Canada Revenue Agency -- Budget, Allocation, Payment
413 |
414 | The Canada Revenue Agency (CRA) has assembled a cross-functional FinOps using stakeholders from their Cloud Business Office (CBO) and Financial Advisory Services. This team undertakes the work of forecasting, budgeting, and tracking actual expenses.
415 |
416 | ![][1]
417 |
418 | The process of forecasting, allocation, and payment at CRA is described as follows:
419 |
420 | 1. Annually, the Cloud Business Office (CBO) forecasts the spend for Azure and AWS, with a breakdown per Cloud Business Requirement. Adjustments are made during the year based on need, avoiding Q4 when possible
421 |
422 | 2. CBO makes a request to Central IT for commitment (funds added to requisition/order in CRA's SAP system)
423 |
424 | 3. IT Contracting puts in place the Cloud Brokering Service Orders per Cloud Business Requirement selecting the Pay-as-you-go model (i.e. you get invoiced for what you use, no upfront costs or purchase commitments)
425 |
426 | 4. Monthly invoices are reconciled and paid from Central IT's budget
427 |
428 | 5. Finance charges back actual costs to business owners as per cost allocation tagging, plus the 10% Cloud Brokering Service. An internal transfer of funds is recovered to Central IT
429 |
430 | Notes:
431 |
432 | 1. Chargebacks are quarterly starting at P3 and then monthly in Q4
433 |
434 | 2. FY-end funding transfer cut-off constraint: midway through March, finance forecasts the anticipated spend for charging back, risk managing the delta
435 |
436 | 3. Shared Costs chargeback model is being developed in 2022
437 |
438 | ![][2]
439 |
440 | ## Statistics Canada -- Finops Organization
441 |
442 | When Statistics Canada committed to migrating its application portfolio to cloud, they underwent a large change management not only in technology, but also in governance and practices. Part of that was investing in FinOps and establishing a FinOps organization. Statcan brings together people from the financial and technology organizations to monitor, management, and optimize cloud spend.
443 |
444 | ![][3]
445 |
446 | ## Canada Revenue Agency -- FinOps Training
447 |
448 | When CRA began its FinOps journey, they wanted to provide the opportunity to stakeholders from technology and finance to understand FinOps practices. The [FinOps Foundation][4] is the learning provider they turned to for increasing organizational learning
449 |
450 | ![][5]
451 |
452 |
453 | ## Statistics Canada -- FinOps Reporting
454 |
455 | To enable departmental monitoring and governance over cloud spend, StatCan has invested in tailored dashboards and reporting to attribute costs back to lines of business and fund centres.
456 |
457 | ![][6]
458 |
459 | [^1]: Delivery Team refers to a multi-disciplinary team responsible for delivering a product using cloud. Deliver Team is used to denote the shift from organizing as functional silos towards multi-disciplinary teams made up of developers who build and run the product, architects, security, product managers, and user interface experts.
460 |
461 |
462 |
463 |
464 |
465 |
466 | Guide sur la gestion des coûts de l'informatique en nuage du gouvernement du Canada
467 | -----------------------------------------------------------------------------------
468 |
469 | # Objet
470 |
471 | Le présent document vise à effectuer ce qui suit :
472 |
473 | - Soutenir l'adoption de l'infonuagique par les organisations du gouvernement du Canada tout en exerçant une diligence raisonnable sur le plan financier et en conservant une certaine souplesse;
474 |
475 | - Définir un ensemble de pratiques permettant d'assurer la gestion des coûts dans l'environnement infonuagique sans nuire à l'agilité et aux autres attributs du nuage;
476 |
477 | - Fournir aux parties prenantes un aperçu de la gestion des coûts de l'infonuagique, y compris les agents financiers et les agents d'approvisionnement.
478 |
479 | # Contexte
480 |
481 | L'informatique en nuage se base sur des modèles de paiement à vue et par répartition pour l'informatique, le stockage, le réseau, les plateformes et les solutions opérationnelles. Les coûts de l'infonuagique sont fluides et directement liés au prix unitaire des ressources multiplié par l'utilisation (coût = prix x utilisation). Il s'agit d'un changement fondamental par rapport aux modèles de consommation informatique traditionnels et fixes où le coût principal est associé à l'acquisition de matériel ou à l'octroi de licences de logiciels. Dans un modèle infonuagique, le coût constitue un facteur direct de l'architecture des applications. Les dépenses en infonuagique sont beaucoup plus dynamiques que celles dans les modèles de TI traditionnels, car les changements à l'utilisation entraînent des changements de coût immédiats. Il s'ensuit une boucle de rétroaction immédiate entre l'utilisation et coût. Les contrôles traditionnels des dépenses s'appuient fortement sur des contrôles au niveau du processus avec une surveillance exigeante en ressources humaines. Ces pratiques traditionnelles ne conviennent pas à un environnement infonuagique, car elles peuvent avoir une incidence négative sur l'agilité souhaitée par les équipes de livraison lors de l'utilisation du nuage et abaisser la valeur opérationnelle. Bien que les agents des finances et d'approvisionnement ne soient pas les gardiens des dépenses liées au nuage, ils aident les équipes de livraison à fixer le budget pour la livraison de leurs produits. Les équipes de livraison sont directement responsables des coûts du nuage et doivent être prêtes à suivre, analyser et optimiser les coûts associés à leurs produits et découlant de leur utilisation. Ces pratiques sont souvent appelées « OpFin ». Les OpFin sont un ensemble de pratiques qui favorisent la gestion et l'optimisation des dépenses dans le nuage sans nuire à l'agilité et à la rapidité de la prestation des services infonuagiques.
482 |
483 | # OpFin
484 |
485 | Souvent, le terme « OpFin » est appliqué à la gestion des coûts du nuage. Le terme est un mot-valise formé à partir des mots « opérations » et « financières ». La pratique est soutenue par la [Fondation des OpFin], une fondation dirigée par la collectivité. La fondation et les consultants en technologies ont construit et ont publié une banque de renseignements sur ce sujet. Le présent guide ne doit pas être lu isolément de cette banque de renseignements. Les OpFin constituent un domaine qui évolue au même rythme que le nuage.
486 |
487 | # Comparaison des modèles traditionnels avec le modèle infonuagique
488 |
489 | On peut penser au passage des modèles de TI traditionnels à un modèle infonuagique en utilisant l'analogie du passage du creusement et de l'entretien de son propre puits à la connexion au réseau municipal d'alimentation en eau. Les deux servent de sources d'approvisionnement en eau, mais chacune a un modèle sous-jacent différent. Dans le cas d'un puits, vous devez assumer la responsabilité de l'achat de l'équipement, de l'ingénierie et de la construction du puits, en plus de veiller à l'entretien des pompes et à la qualité de l'eau. Dans le cas d'un réseau municipal d'alimentation en eau, on vous facture simplement le service en fonction de la consommation mensuelle indiquée sur votre compteur d'eau et vous êtes abstrait des actifs nécessaires à la livraison de l'eau. Ce principe n'est pas tellement différent de celui du changement qu'a entraîné le modèle infonuagique. Les modèles informatiques traditionnels, tout comme le creusement de puits, constituent un modèle de livraison à forte intensité de capital et d'actifs. En revanche, le modèle infonuagique, tout comme l'approvisionnement en eau municipal, transforme l'approvisionnement informatique en un service primaire.
490 |
491 | Dans le tableau ci-dessous, on suppose que le modèle à la carte dans le nuage est maintenu. Il convient de noter que selon la façon dont votre organisation établit la structure de son accord avec les fournisseurs, certaines parties de ce tableau peuvent ne pas s'appliquer. Par exemple, si un contrat oblige le consommateur à payer à l'avance pour des années de services, certaines des exigences énoncées dans ce tableau ne s'appliqueront pas. De plus, la portée de ce tableau est les services infonuagiques eux-mêmes et n'inclut pas les coûts en capital pour la mise en œuvre ou l'extension des services ou la construction de ces derniers à l'intérieur de ces plateformes.
492 |
493 | | Modèles de TI traditionnels|Modèles infonuagiques|
494 | |----------------------------|---------------------|
495 | |Les services de TI traditionnels reposent sur un modèle de dépenses en capital où les biens (les logiciels, les matériels et les installations) sont achetés et conservés comme des actifs pendant une durée de vie déterminée.| Le service infonuagique est une dépense d'exploitation, tout comme un service public tel que l'électricité ou l'eau municipale, où les coûts varient en fonction du niveau d'utilisation.|
496 | |Le niveau de consommation d'un actif (matériel et logiciel) n'a pas d'incidence importante sur le coût. Une fois que l'actif est acheté, les coûts sont irrécupérables et il n'existe aucun mécanisme pour optimiser ces coûts après que l'achat a été fait.|La consommation de ressources infonuagiques entraîne des coûts. La désactivation de l'utilisation d'un service permet de réaliser des économies de coûts.|
497 | |Les investissements dans les modèles traditionnels sont généralement périodiques et sont associés au remplacement des biens vieillissants.| Les coûts des modèles infonuagiques sont à perpétuité jusqu'à la désactivation du service.|
498 | |Les modèles traditionnels ont des coûts fixes.|Les coûts des modèles infonuagiques sont variables.|
499 | |L'établissement de rapports sur les coûts des modèles traditionnels a lieu de façon périodique, souvent sur une base annuelle, car les coûts sont en grande partie fixes. |Les coûts des modèles infonuagiques sont en temps réel, car ils sont variables|
500 | |Les modèles traditionnels ont un facteur de coût simple.|L'établissement des coûts des modèles infonuagiques est complexe et est souvent composé de microtransactions permettant de suivre chaque utilisation.|
501 | |L'achat d'immobilisations est géré de manière centralisée par les organisations financières et d'approvisionnement.| Les achats des services infonuagiques sont décentralisés et sont effectués par les équipes de livraison fournissant des produits numériques à l'aide du nuage.|
502 |
503 |
504 | # Optimiser les coûts du nuage
505 |
506 | Si on le compare aux modèles de TI traditionnels, le modèle infonuagique offre plus d'options pour façonner les dépenses. Des leviers de décisions portant sur l'optimisation peuvent être utilisés pour réduire le gaspillage et déterminer la consommation appropriée. À l'inverse, des décisions peuvent être prises pour dépenser plus afin d'obtenir une plus grande vitesse et faciliter le déploiement. On peut produire une représentation graphique des choix d'optimisation sur un quadrant simple pour illustrer les compromis qui doivent être faits au chapitre du temps et du coût, comme le montre la figure 2. L'optimisation est axée sur la réduction du gaspillage et le contrôle des dépenses. L'optimisation continue peut ne pas entraîner de réduction des dépenses globales dans le nuage à long terme. Souvent, les organisations continuent d'augmenter leur utilisation du nuage avec le temps sous la forme de nouveaux services, de nouvelles données et de nouvelles expériences utilisateur. La numérisation accrue des activités d'une organisation entraînera, au fil du temps, une augmentation globale des dépenses liées au nuage. L'optimisation peut aider à assurer que les dépenses sont bien gérées et qu'elles n'entraînent pas de gaspillage inutile.
507 |
508 | ## Boucles de rétroaction
509 |
510 | L'un des attributs clés de la gestion des coûts dans le modèle infonuagique dépend de la boucle de rétroaction en temps réel entre l'utilisation du nuage et les coûts du nuage. Cette simple boucle de rétroaction favorise l'adoption de comportements financiers permettant d'optimiser l'utilisation du nuage pour réduire les dépenses inutiles.
511 |
512 | ## Optimisation de la valeur opérationnelle, non la réduction au minimum des coûts
513 |
514 | L'objectif de la gestion des coûts ne vise pas à réduire au minimum les coûts, mais plutôt à :
515 |
516 | 1. réduire le gaspillage;
517 |
518 | 2. permettre une offre de la valeur opérationnelle.
519 |
520 | La réduction au minimum des coûts peut avoir une incidence sur la valeur opérationnelle. Les équipes de livraison et les propriétaires d'entreprise peuvent être prêts à faire des compromis et à payer des coûts plus élevés pour être en mesure d'assurer une livraison plus rapide. Par exemple, il se peut qu'une équipe de livraison opte pour le déploiement d'une architecture qui n'est pas optimisée tout simplement parce qu'une architecture plus simple peut permettre une livraison plus rapide d'une solution. Les compromis qui sont faits entre les économies pouvant être générées et l'effort nécessaire à la réalisation de ces économies sont illustrés ci-dessous. Un autre exemple est la priorité accordée au lancement d'une nouvelle fonctionnalité au détriment d'un autre affacturage d'un morceau de code qui pourrait entraîner une baisse des coûts du nuage. Par conséquent, l'optimisation des coûts fait partie intégrante des éléments de carnet d'un produit. Les possibilités d'optimiser un produit pour réduire les coûts doivent être hiérarchisées avec d'autres éléments de carnet d'un produit, comme l'ajout de nouvelles expériences utilisateur, l'application de nouvelles règles et l'inclusion d'autres demandes de fonctionnalités.
521 |
522 | La gestion des coûts du nuage ne vise pas à réduire les coûts au minimum, mais plutôt à réaliser une vérification diligente sur le plan financier tout en améliorer la valeur commerciale pour l'organisation.
523 |
524 | # Rôles
525 |
526 | Ce document présente les rôles que doivent jouer les organisations pour exercer une diligence raisonnable à l'égard des dépenses liées au nuage. Il ne vise pas à fournir un ensemble exhaustif de pratiques, mais plutôt à décrire les pratiques minimales suggérées.
527 |
528 | |no.|role|
529 | |---|-----|
530 | |01|Responsabilité|
531 | |02|Visibilité et transparence|
532 | |03|Attribution des coûts|
533 | |04|Budgétisation|
534 | |05|Politiques sur les services et alertes|
535 | |06|Optimisation|
536 | |07|Limitation des coûts|
537 | |08|Gouvernance|
538 | |09|Définition des paramètres opérationnels|
539 |
540 |
541 | # 01 Responsabilité
542 |
543 |
544 | ## Objectif
545 |
546 | Les équipes de livraison[^1] doivent être prêtes à assumer des responsabilités quant à la gestion et à l'optimisation des coûts. Les répercussions des conceptions architecturales et des choix d'approvisionnement doivent être comprises par les membres de l'équipe de livraison.
547 |
548 | ## Description des activités
549 |
550 | - Veiller à ce que les équipes de livraison connaissent les conséquences de leurs décisions en matière de consommation, de configuration et d'architecture sur les coûts
551 |
552 | - Envisager de définir une exigence de formation sur la gestion financière dans le nuage (OpFin) pour tous les membres de l'équipe de livraison
553 |
554 | - S'assurer que les concepts de base des pratiques des OpFin et les garde-fous énumérés dans ce document soient compris par les membres de l'équipe de livraison
555 |
556 | - Utiliser l'approche RACI (responsable, agent comptable, consulté et informé) des OpFin du gouvernement du Canada (lien requis) comme modèle pour l'adapter aux rôles de votre organisation
557 |
558 | - Déterminer un rôle centralisé au sein de votre organisation qui gérera les données liées au nuage et les décisions relatives à la structure de gouvernance de votre organisation. Il ne s'agit pas nécessairement d'un rôle confié au centre d'expertise en infonuagique, mais fait plutôt partie de ses responsabilités.
559 |
560 | - Déterminer le rôle des agents financiers dans les pratiques des OpFin de votre organisation.
561 |
562 | ## Références
563 |
564 | -
565 |
566 | -
567 |
568 | # 02 Visibilité et transparence
569 |
570 |
571 | ## Objectif
572 |
573 | Permettre aux équipes de livraison d'accéder librement aux rapports sur les coûts. Les équipes de livraison doivent avoir une vue complète sur les services et l'utilisation qui entraînent à l'augmentation des coûts des services infonuagiques associés à la livraison de leurs produits. Être transparent auprès de toutes les parties prenantes au sujet des coûts des services infonuagiques.
574 |
575 | ## Description des activités
576 |
577 | - Fournir des rapports et des tableaux de bord sur les dépenses passées, actuelles et prévues relatives aux services infonuagiques aux intervenants
578 |
579 | - Fournir des rapports de coûts standardisés à toutes les équipes de livraison, mais permettre aux équipes de livraison d'adapter ces rapports à leurs besoins
580 |
581 | - Fournir des rapports de manière à ce qu'une équipe de livraison puisse isoler les coûts associés à la livraison de ses produits
582 |
583 | - Maintenir la visibilité de tous les comptes et services infonuagiques. Si votre organisation a recours aux services infonuagiques de plusieurs fournisseurs, la visibilité de l'ensemble des fournisseurs et des comptes devra être assurée.
584 |
585 | - Offrir à tous les intervenants une transparence quant aux coûts des services infonuagiques.
586 |
587 | - Fixer la limite des dépenses de l'organisation associées aux services infonuagiques. Par exemple, le dirigeant principal de l'information ou le dirigeant principal des finances s'intéressent-ils aux rapports mensuels?
588 |
589 | ## Références
590 |
591 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
592 |
593 | ## Automatisation
594 |
595 | - Vérifier que le tableau de bord ou l'interface de protocole d'application (API) de facturation est utilisé sur une base périodique
596 |
597 | - Vérifier que le développeur et l'architecte ont également accès à la console et aux API de facturation
598 |
599 | # 03 Attribution des coûts
600 |
601 | ## Objectif
602 |
603 | Établir une structure pour l'étiquetage des ressources infonuagiques et l'attribution des coûts aux secteurs d'activité et aux centres de coûts qui financent ces coûts.
604 |
605 | ## Description des activités
606 |
607 | - Consigner et approuver un ensemble normalisé de balises pour identifier comment le coût des ressources est attribué aux applications et aux secteurs d'activité aux fins de facturation.
608 |
609 | - Consigner et approuver une structure hiérarchique des ressources ou des regroupements qui prennent en charge l'attribution des coûts aux secteurs d'activité aux fins de facturation.
610 |
611 | - Utiliser l'étiquetage et les structures des ressources pour assurer des possibilités de rapport supplémentaires afin que les coûts puissent être attribués aux secteurs d'activité et aux centres de financement qui financent la livraison des produits.
612 |
613 | - Rechercher et corriger toutes les ressources non étiquetées ou les ressources qui existent en dehors des structures de répartition des coûts.
614 |
615 | - Maintenir l'hygiène en matière des ressources :
616 |
617 | - Identifier et corriger les ressources orphelines;
618 |
619 | - Utiliser l'automatisation lors de la mise en œuvre de politiques de service pour appliquer les normes d'hygiène en matière de balisage dans la mesure du possible.
620 |
621 | - Pour les ressources de la plateforme infonuagique commune qui ne peuvent pas être attribuées à un seul produit ou secteur d'activité :
622 |
623 | - Établir une méthode d'attribution des coûts communs, par exemple :
624 |
625 | - Proportionnelle : basée sur le pourcentage relatif des coûts directs (par exemple, 10 % des dépenses directes relatives aux services infonuagiques);
626 |
627 | - À parts égales : montant total réparti de façon égale entre les produits (par exemple, en divisant les coûts communs par le nombre de produits);
628 |
629 | - Fixe : semblable à l'attribution à parts égales, mais en y incluant un coefficient pour pondérer la proportion allouée à chaque produit. La somme de tous les coefficients doit être 1 (par exemple, 0,3 des coûts communs).
630 |
631 | - Déterminer une méthodologie de facturation ou de rétrofacturation pour rendre les coûts communs visibles pour chaque produit.
632 |
633 | ## Références
634 |
635 | - https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-allocation-basics-that-you-need-to-know/
636 |
637 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
638 |
639 | ## Automatisation
640 |
641 | - Vérifier les ressources qui n'ont pas de balises approuvées de répartition des coûts.
642 |
643 | - Utiliser des règles de service pour appliquer les balises de répartition des coûts obligatoires.
644 |
645 | # 04 Budgétisation
646 |
647 |
648 |
649 | ## Objectifs
650 |
651 | Les équipes de livraison établissent les budgets des produits en collaboration avec les agents financiers et entreprennent des activités pour suivre les coûts réels par rapport aux prévisions.
652 |
653 | ## Description des activités
654 |
655 | - L'équipe de livraison travaillera avec les agents financiers pour établir un budget pour leur produit en fonction de l'estimation des coûts de l'hébergement dans les nuages.
656 |
657 | - Les budgets doivent être ventilés par période de facturation. Des alertes doivent être mises en place pour informer les équipes de livraison lorsqu'un pourcentage prédéterminé du budget mensuel prévu est dépensé.
658 |
659 | - Les équipes de livraison doivent rapporter les chiffres réels par rapport aux prévisions pour déterminer si le temps d'absorption correspond aux prévisions.
660 |
661 | - La gouvernance doit être documentée pour inclure le processus et les critères pour accroître les budgets.
662 |
663 | - La gouvernance du budget doit permettre une utilisation et des coûts imprévus, mais également prévoir des mesures correctives pour aider les équipes de livraison à gérer les dépenses imprévues répétitives.
664 |
665 | ## Références
666 |
667 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
668 |
669 | - https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/
670 |
671 | -
672 |
673 | ## Automatisation
674 |
675 | - Vérifier que les fonctionnalités des fournisseurs de services infonuagiques ont été configurées pour établir des budgets et envoyer des alertes sur ces derniers.
676 |
677 | # 05 Politique et alertes
678 |
679 |
680 | ## Objectifs
681 |
682 | Utiliser des alertes pour lancer des signaux d'alerte précoces lorsque des jalons financiers clés sont atteints, tels que le pourcentage des dépenses par rapport au budget total. Utiliser des politiques de service pour appliquer des garde-fous financiers clés tels que le respect des normes de balisage.
683 |
684 | ## Description
685 |
686 | - Utiliser la capacité des plateformes infonuagiques à alerter les utilisateurs des événements financiers comme méthode permettant d'automatiser les activités de gouvernance.
687 |
688 | - Utiliser des politiques de service pour faire respecter les principaux garde-fous financiers tels que le balisage et l'automatisation de la désactivation des services, en particulier pour les environnements de test et de développement. Les garde-fous financiers diffèrent des mesures de protection du nuage du gouvernement du Canada, car ils sont propres à chaque ministère et axés sur la gouvernance financière.
689 |
690 | ## Références
691 |
692 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
693 |
694 | -
695 |
696 | -
697 |
698 | -
699 |
700 | ## Automatisation
701 |
702 | - Configurer des alertes pour les comptes ou les groupes de ressources afin d'informer les membres de l'équipe de livraison lorsque 25 %, 50 % et 75 % (ou toute autre valeur convenant à votre contexte) des ressources du budget total de l'équipe ont été consommées.
703 |
704 | - Définir des alertes en cas de variations excessives en pourcentage des coûts survenant sur une courte période.
705 |
706 |
707 |
708 | # 06 Optimisation
709 |
710 |
711 | ## Objectifs
712 |
713 | Les équipes de livraison doivent analyser continuellement les occasions pour optimiser l'utilisation et les architectures des services afin de réaliser des économies de coûts. Les équipes centralisées des OpFin peuvent cerner des possibilités d'optimisation pour aider les équipes de livraison à prendre des décisions d'optimisation.
714 |
715 | ## Description des activités
716 |
717 | - Les équipes de livraison examineront les rapports sur les coûts et de facturation pour cerner des possibilités d'optimisation et identifier les sources de gaspillage.
718 |
719 | - Elles compareront les avantages et les coûts de la mise en œuvre des stratégies d'optimisation
720 |
721 | - Les possibilités d'optimisation des architectures et de l'utilisation doivent être ajoutées au carnet de fonctionnalités du produit pour être priorisées aux côtés des demandes de fonctionnalités des utilisateurs et de la remédiation de la dette technique. L'objectif n'est pas de trouver la solution la moins chère à tout prix. Une solution plus chère peut être tolérée si elle peut permettre une plus grande vitesse de livraison.
722 |
723 | - Identifier les sources possibles de gaspillage telles que les ressources ayant un faible taux d'utilisation.
724 |
725 | - Adapter les ressources, telles que les machines virtuelles, en analysant les paramètres de rendement. Limiter les ressources utilisées dans la mesure du possible.
726 |
727 | - Utiliser les services d'optimisation des coûts des fournisseurs infonuagiques pour examiner les recommandations et décider sur l'exécution de ces recommandations.
728 |
729 | - S'appuyer sur la mise à l'échelle horizontale pour augmenter les ressources pendant les périodes de pointe.
730 |
731 | - Aligner la capacité et la demande en utilisant l'élasticité de la mise à l'échelle horizontale et verticale.
732 |
733 | - Désactiver les ressources qui ne sont pas utilisées en dehors des heures régulières, comme les environnements de développement et de test.
734 |
735 | - Analyser les modèles d'utilisation pour cerner les possibilités de passer aux instances réservées pour réaliser des économies de coûts.
736 |
737 | - Utiliser le service offrant une plus grande possibilité de réduire les coûts à l'utilisation. Par exemple, même si le passage des machines virtuelles aux plateformes sans serveur offrira une plus grande granularité des coûts, il faut également compte tenir compte du fait que le coût de la refactorisation qui peut annuler les économies de coûts réalisées.
738 |
739 | ## Références
740 |
741 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
742 |
743 | -
744 |
745 | - Maximize Business Value with Cloud FinOps, Google Cloud, https://services.google.com/fh/files/blogs/cloud_finops_paper.pdf
746 |
747 | ## Automatisation
748 |
749 | - Rendre compte du nombre de demandes de fonctionnalités dans les carnets de produits qui sont liées à l'optimisation des coûts.
750 |
751 | - Automatiser la mise hors service périodique des ressources pour les environnements de développement et de test en dehors des heures d'utilisation, par exemple, les heures de base.
752 |
753 | - Rendre compte du nombre d'instances de calcul et de stockage provisionnées et des tendances au fil du temps.
754 |
755 | # 07 Limitation des coûts
756 |
757 | ## Objectifs
758 |
759 | Lorsque les coûts liés à l'infonuagique dépassent ce qui avait été prévu, il faut mettre en œuvre un plan d'action pour analyser l'utilisation actuelle et réduire le gaspillage.
760 |
761 | ## Description des activités
762 |
763 | Lorsque les dépenses imprévues augmentent, les équipes doivent mettre en œuvre un plan pour limiter la croissance des dépenses :
764 |
765 | - Rendre compte de la croissance inattendue des coûts au Comité de gouvernance;
766 |
767 | - Présenter un plan d'action au Comité de gouvernance pour faire face à la croissance inattendue des coûts;
768 |
769 | - Demander l'autorisation du Comité de gouvernance pour exécuter un plan d'action pour remédier à la croissance inattendue des coûts;
770 |
771 | - Rassembler les intervenants impliqués pour former une équipe spéciale;
772 |
773 | - Effectuer des examens rétrospectifs sans blâme comme méthode d'apprentissage des dépassements de coûts accidentels dans le but d'améliorer les pratiques futures au lieu de blâmer;
774 |
775 | - Effectuer une analyse de base. Déterminer la source des augmentations de dépenses imprévues;
776 |
777 | - Retracer la croissance des dépenses aux activités commerciales sources;
778 |
779 | - Fixer des objectifs réalisables pour la réduction des dépenses. Cerner les occasions de réduire le gaspillage et d'optimiser l'utilisation des ressources;
780 |
781 | - Mettre en place des activités de réduction des dépenses.
782 |
783 | ## Références
784 |
785 | - Cloud Cost Optimization, Gartner, Mike Brown
786 |
787 | - Maximize Business Value with Cloud FinOps, Google Cloud, https://services.google.com/fh/files/blogs/cloud_finops_paper.pdf
788 |
789 | -
790 |
791 | # 08 Gouvernance
792 |
793 |
794 |
795 | ## Objectifs
796 |
797 | Concevoir et introduire un cadre de gouvernance pour examiner l'analyse des coûts du modèle infonuagique et adopter les mesures qui s'imposent, le cas échéant.
798 |
799 | ## Description des activités
800 |
801 | - Accroître la transparence des coûts du nuage en rendant compte, notamment :
802 |
803 | - des coûts par fournisseur et par produit;
804 |
805 | - des coûts partagés;
806 |
807 | - des dépenses par rapport aux budgets et aux prévisions;
808 |
809 | - des tendances au fil du temps;
810 |
811 | - des équipes de livraison et des produits les plus performants et les moins performants en ce qui concerne l'optimisation des coûts.
812 |
813 | - Créer des processus de surveillance et de prise de mesures correctives sans nuire la rapidité de livraison ni à la souplesse des ressources infonuagiques.
814 |
815 | - Décider des garde-fous financiers et des produits que doivent respecter toutes les équipes de livraison et leur en aviser.
816 |
817 | - La gouvernance des coûts ne nécessite pas une structure de gouvernance verticale dédiée, mais peut être intégrée à d'autres activités de gouvernance telles que la performance, l'architecture et la sécurité.
818 |
819 | - Documenter les rôles et responsabilités associés à la gestion des coûts du nuage.
820 |
821 | - Favoriser les garde-fous au détriment des points de contrôle pour faire respecter les exigences de la politique.
822 |
823 | ## Références
824 |
825 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
826 |
827 | -
828 |
829 | # 09 Paramètres opérationnels
830 |
831 |
832 | ## Objectifs
833 |
834 | La numérisation et l'automatisation accrues des services augmenteront les coûts du nuage au fil du temps, une augmentation qui ne pourra être renversée par aucun effort d'optimisation. Les coûts des services infonuagiques en termes des activités pouvant être réalisées à l'aide de ces services doivent être expliqués aux propriétaires d'entreprise. Les équipes de livraison doivent être en mesure de rendre compte des coûts des services infonuagiques dans le contexte des mesures opérationnelles. Les aspects économiques unitaires, notamment le coût unitaire, doivent être calculés et déclarés.
835 |
836 | ## Description des activités
837 |
838 | - Collaborer avec les propriétaires d'entreprise pour comprendre leurs mesures de prestation de services numériques (par exemple, le nombre de demandes de renseignements, les temps d'attente, le nombre de transactions, la rapidité des transactions, le délai d'exécution des transactions, la valeur totale des transactions, la rentabilité, etc.).
839 |
840 | - Rendre compte des coûts du nuage en termes de paramètres de prestation de services numériques (par exemple, le coût moyen pour répondre à une demande est de X dollars).
841 |
842 | - Exprimer les investissements technologiques en termes de l'amélioration aux mesures de prestation de service (par exemple, une augmentation de l'investissement accru se traduira par une capacité accrue à répondre à un plus grand nombre de demandes).
843 |
844 | - Rendre compte des tendances des coûts et des paramètres de prestation de services numériques au fil du temps.
845 |
846 | ## Références
847 |
848 | - Cloud FinOps: Collaborative, Real-Time Cloud Financial Management by J.R. Storment and Mike Fuller
849 |
850 | -
851 |
852 | # Cas d'utilisation
853 |
854 | ## Secrétariat du Conseil du Trésor du Canada -- Optimisation à l'aide des instances réservées
855 |
856 | Le Secrétariat du Conseil du Trésor du Canada (SCT) a migré l'intégralité de son portefeuille de plus de 120 applications vers le nuage en 2020. Au cours de cette période, il a acquis une expérience considérable dans l'optimisation de son utilisation du nuage. Le passage aux instances réservées était l'un des moyens par lequel le SCT a optimisé son utilisation des machines virtuelles. La décision d'acheter des machines virtuelles sur une période de trois ans a permis de réaliser des économies de 60 % ou plus comparativement aux modèles à la carte. Le SCT a calculé que, dans la plupart des cas, une instance réservée atteint le seuil de rentabilité après 15 mois. Cela signifie que même si la machine virtuelle n'est utilisée que pendant 15 mois sur la période totale d'achat de 36 mois, des économies de coûts sont réalisées comparativement à un modèle à la carte. Pour le SCT, qui a automatisé l'arrêt et le démarrage programmés des environnements de développement et de test pour économiser de l'argent, le passage aux instances réservées a permis de réaliser davantage d'économies comparativement à la planification et avec un niveau de complexité moindre.
857 |
858 | Outre la migration vers des instances réservées, le SCT a également constaté que la définition et l'exécution des périodes de conservation des registres permettent d'importantes économies. La définition d'une politique sur la conservation des registres et le nettoyage périodique subséquent des registres qui ont dépassé la période limite pour le stockage des blocs et des plateformes en tant que service permettent d'éviter des coûts.
859 |
860 | ## Agence du revenu du Canada -- Budget, allocation, et paiement
861 |
862 | L'Agence du revenu du Canada (ARC) a assemblé une solution OpFin interfonctionnelle en utilisant les intervenants de son bureau d'affaires infonuagique et des services consultatifs en gestion financière. Cette équipe entreprend le travail de prévision, de budgétisation et de suivi des dépenses réelles.
863 |
864 | ![][2]
865 |
866 | Le processus d'établissement des prévisions, d'affectation et de paiement à l'ARC est décrit comme suit :
867 |
868 | 1. Chaque année, le bureau des opérations des services infonuagiques prévoit les dépenses pour Azure et Amazon Web Services (AWS), avec une ventilation par exigence opérationnelle infonuagique. Des ajustements sont effectués au cours de l'année en fonction des besoins, en évitant le quatrième trimestre lorsque cela est possible.
869 |
870 | 2. Le bureau des opérations des services infonuagiques fait une demande d'engagement au service informatique central (pour ajouter des fonds à la demande et passage de la commande dans le système SAP de l'ARC).
871 |
872 | 3. L'équipe de la passation de contrats de TI met en place les commandes de service de courtage infonuagique par exigence commerciale infonuagique en sélectionnant le modèle de paiement à l'utilisation (c'est-à-dire, que vous ne payez que pour les services que vous utilisez, sans avoir à payer de frais initiaux ni d'engagement d'achat).
873 |
874 | 4. Les factures mensuelles sont réconciliées et payées à partir du budget des services de TI centraux.
875 |
876 | 5. Le service des finances refacture les coûts réels aux propriétaires d'entreprise selon la répartition des coûts, en y incluant un supplément de 10 % pour le service de courtage infonuagique. Un transfert de fonds interne est effectué vers l'organisation centrale de TI.
877 |
878 | Notes :
879 |
880 | 1. Les refacturations sont effectuées sur une base trimestrielle à partir du T3, puis sur une base mensuelle à compter du T4.
881 |
882 | 2. Contrainte d'arrêt des transferts de financement de fin d'exercice : à la mi-mars, le service des finances effectue la prévision des dépenses pour la refacturation et la gestion du risque delta.
883 |
884 | 3. Le modèle de refacturation des coûts partagés est en cours d'élaboration en 2022.
885 |
886 | ![][3]
887 |
888 | ## Statistique Canada -- Organisation OpFin
889 |
890 | Lorsque Statistique Canada s'est engagé à migrer son portefeuille d'applications vers le nuage, il a subi une importante gestion du changement non seulement sur le plan de la technologie, mais aussi en ce qui concerne la gouvernance et les pratiques. Une partie de cela consistait à investir dans les OpFin et à créer une organisation OpFin. Statcan regroupe des gens de différentes organisations financières et technologiques pour surveiller, gérer et optimiser les dépenses liées à l'infonuagique.
891 |
892 | ![][4]
893 |
894 | ## Agence du revenu du Canada -- Formation sur les OpFin
895 |
896 | Lorsque l'ARC a commencé son parcours des OpFin, elle souhaitait offrir aux intervenants des secteurs de la technologie et des finances la possibilité de comprendre les pratiques des OpFin. La [Fondation des OpFin][5] est le fournisseur des services de formation vers lequel elle s'est tournée pour accroître l'apprentissage organisationnel.
897 |
898 | ![][6]
899 |
900 |
901 | ## Statistique Canada -- Rapports des OpFin
902 |
903 | Pour assurer le contrôle et la gouvernance ministériels des dépenses liées aux services infonuagiques, StatCan a investi dans des tableaux de bord et des rapports personnalisés pour attribuer les coûts aux secteurs d'activité et aux centres de financement.
904 |
905 | ![][7]
906 |
907 | [^1]: L'équipe de livraison fait référence à une équipe multidisciplinaire responsable de la livraison d'un produit à l'aide du nuage. Le terme « équipe de livraison » est utilisé pour désigner le passage d'une organisation en silos fonctionnels vers des équipes multidisciplinaires composées de développeurs qui élaborent et qui exécutent le produit, d'architectes, de responsables de la sécurité, de chefs de produit et d'experts de l'interface utilisateur.
908 |
909 |
910 |
911 |
912 |
--------------------------------------------------------------------------------
103 |
104 |
105 | # 5. User Technology