Il y a beaucoup de messages sur ce à quoi ressemble une interview de codage typique chez Google. Mais, bien qu'il ne soit pas aussi largement décrit et discuté, il y a aussi très souvent un entretien de conception de système. Pour un poste SRE, c'est NALSD: conception de grands systèmes non abstraite. La principale différence entre les entretiens SWE et SRE réside dans ces deux lettres: NA.
Alors, quelle est la différence? Comment se préparer à cet entretien? Soyons non abstraits et utilisons un exemple. Pour être plus non abstrait, prenons quelque chose du monde matériel, de sorte que l'on ne vous demandera pas exactement la même chose lors de la vraie interview (du moins, pas lors de l'interview de Google) :)
Concevons donc un système de bibliothèque publique. Pour les livres papier, comme vous en avez vu partout. L'ensemble du texte ci-dessous a été écrit en une heure environ, pour vous montrer approximativement les domaines que vous devriez pouvoir couvrir / toucher pendant l'entretien. Veuillez excuser un peu de désordre, c'est comme ça que je pense (donc je le suis).
Entretien NALSD: concevoir un système de bibliothèque publique.
Tout d'abord, nous rassemblons les caractéristiques de la charge, soit via des questions à l'intervieweur, soit en faisant une supposition raisonnable (sans oublier de le dire à voix haute). Étant donné que l'entretien concerne des systèmes évolutifs, nous nous attendons à une ville avec une grande population (disons, 1M +). Nous avons quelques options: un immense bâtiment ou des bibliothèques locales plus un stockage. Je pense que ce dernier est plus raisonnable, car il nous permet également d'étendre le système à plusieurs villes.
Concentrons-nous maintenant sur le système de la ville unique; nous devrions être en mesure d'appliquer à nouveau le même modèle (avec des corrections mineures) pour l'étendre au niveau du pays. Donc, nous avons une ville avec 1M + d'habitants. Pour faciliter les calculs, arrondissons à 1 million de lecteurs possibles. Chaque lecteur veut lire quelque chose indépendamment des autres lecteurs, à des moments arbitraires. Nous pouvons donc modéliser le flux de lecteurs comme un processus de Poisson. Faire le bon calcul est un peu difficile pendant la durée de l'interview, alors simplifions une fois de plus, et disons qu'environ 1% des lecteurs possibles viendraient prendre un livre chaque jour. Supposons donc 10000 demandes de livres par jour.
Donc, notre tâche est devenue maintenant: fournir la possibilité de distribuer 10000 livres par jour (cela signifie également que nous devons être en mesure de reprendre ces 10000 livres un jour plus tard) dans une ville de 1M +. Cette estimation montre que la solution à bâtiment unique ne résistera pas (pour fournir les livres pour les personnes de plus d'un million, notre bibliothèque devrait être accessible dans un délai raisonnable, sinon leur volonté de prendre un livre expirera dans les embouteillages). Essayons donc de deviner quelle taille est raisonnable pour les bibliothèques locales que nous devons construire. Une estimation absolument correcte impliquerait la densité de population, les latences d'accessibilité, etc., mais comme cela n'affectera pas la conception globale, nous pouvons à nouveau la simplifier en considérant une distribution uniforme d'unités similaires. Nous ne savons toujours pas quelle doit être la taille des unités; par exemple, nous pourrions répartir 10 000 bibliothèques avec 1 livre chacune dans la ville, mais cela ne fonctionnera évidemment pas. Aller un niveau plus bas.
Une seule bibliothèque locale. Pour qu'il soit utile, la majorité des visiteurs doivent pouvoir trouver le livre qu'ils souhaitent. Cela signifie que nous devons suivre l'utilisation et prévoir la demande pour les demandes les plus populaires afin d'être prêts à les traiter. De plus, nous devrions avoir une large gamme d'articles moins populaires. Ma approximation est une bibliothèque avec moins de 1000 noms de livres, avec des dizaines d'exemplaires pour les plus populaires et des pièces uniques pour les queues. Le temps moyen pour lire un livre dans notre bibliothèque varie de 3 jours à 2 semaines (bien sûr, le temps réel dépend du livre lui-même, ce qui dans un cas réel nécessiterait une analyse supplémentaire); estimons une semaine par livre. Cela signifie qu'un livre qui a été distribué reviendra dans 1 semaine, nous devrions donc avoir des livres de qualité supérieure pendant 1 semaine (après une semaine, ils sont réapprovisionnés à partir des retours).
Supposons un facteur de gonflement moyen de 6, ce qui nous conduirait à une capacité de stockage unitaire de 6000 livres. Moins de stockage signifierait une pénurie dans les noms les plus populaires (enfin, des unités plus petites pourraient toujours être utiles - comme un petit kiosque de centre commercial avec «Twilight», mais gardons-le en dehors de notre conception maintenant).
Dans un état stable, les rendements et les emprunts quotidiens sont presque similaires (avec une certaine dispersion), mais nous devons également prévoir des rendements de pointe (qui pourraient être des événements de synchronisation externes: vacances, tendances, etc.). La bonne façon est de créer et d'exécuter un modèle statistique. Mais pour l'instant, gardons juste ⅓ comme tampon. Cela signifie que nous devons garder 6000 livres prêts à être distribués, plus de place pour 2000.
Pour résumer: nous avons besoin d'une bibliothèque avec 8 000 livres de stockage. Il devrait être coûteux de le réapprovisionner tous les jours, nous devrions donc nous attendre à ce que cela soit suffisant pour une semaine ou deux. Deux semaines, 6000 livres, avec des retours possibles asymétriques, c'est environ 300 livres par jour. Pour la journée d'ouverture, nous pouvons remplir l'ensemble du stockage (8000 livres) pour ensemencer les 2000 premiers livres en chiffre d'affaires. 2000 en 3 jours = 600 livres par jour, avec tampon asymétrique = 800 livres par jour.
Estimons le débit et les limites de notre stockage. 1 livre représente environ 2 cm linéaires d'espace, 8 000 livres = 160 mètres. Nous pouvons le plier verticalement 4 fois, c'est donc 40 mètres linéaires. Si nous le divisons en racks de ~ 5 mètres, nous obtiendrons 8 racks avec 4 étagères, chacune de 5 mètres de long. Un bibliothécaire (ou robo-bibliothécaire) devrait pouvoir travailler avec deux racks; une extraction d'un seul livre prendra: 5 secondes pour marcher jusqu'aux étagères, 5 secondes pour saisir / mettre le livre à sa place, 5 secondes pour revenir en arrière (15 secondes au total). 4 bibliothécaires nous donneront un débit de pointe de 15 livres par minute. Ainsi, un traitement de 900 livres par heure au maximum.
Si nous prenons également en compte le temps de traitement des demandes (10 s), le temps de recherche (5 s), le temps de suivi dans le système (2 s), nous obtiendrons 400 livres / heure de pointe. Ainsi, nous devrions être capables de gérer notre estimation de 800 livres par jour en 2 heures.
Calculons d'autres aspects: pour pouvoir donner 400 livres / heure à 4 bibliothécaires, nous devons avoir suffisamment d'espace pour 100 personnes faisant la queue, et les portes d'entrée devraient permettre à 400 personnes / heure de marcher dans les deux sens. . Cela signifie que notre principal étranglement serait l'espace d'attente et les portes des bâtiments.
Cela signifie que nous devrions être en mesure de trouver un équilibre optimal entre l'espace de stockage et la zone d'attente lors des calculs appropriés pour la conception réelle.
C'est tout pour ce niveau, il est temps de passer à autre chose. Nous avons une estimation de la demande globale du réseau de bibliothèques comme 10000 livres / jour. Une unité représente 800 livres / jour, nous avons donc besoin de 12,5 unités. Si nous faisons une distribution géographique uniforme, chaque lecteur devrait être dans la plage de 1-2 unités (à la limite de la ville) et 3-4 (à l'intérieur de la ville). Cela donnerait la possibilité de lisser un peu les pics et / ou de couvrir les pénuries de livres supérieurs.
Nous savons également que chaque bibliothèque peut être fermée à tout moment (incendie, inspection, poignées de porte de réfrigérateur repeintes, etc.) et que plus nous avons d'unités, plus la probabilité de coïncidence de ces événements est élevée. Ainsi, nous avons besoin d'une unité redondante pour 5 à 6 unités. Donc, au total, nous avons besoin de 15 unités pour répondre aux demandes de notre ville, si nous maintenons l'approvisionnement requis dans chaque unité.
Comme nous l'avons déjà pensé plus tôt, nous devons reconstituer le stockage chaque semaine ou deux (plus tôt, nous en avons deviné deux) - environ la moitié du stockage doit être remplacée, pour suivre les tendances, etc. Donc, 4000 livres de nouvelle livraison et 4000 livres retirés. À chaque réapprovisionnement, nous devons extraire 4000 livres et réinsérer 4000 nouvelles entrées. Avec notre débit de 400 livres / heure, un réapprovisionnement sera de 10 heures très intenses. Eh bien, cela semble toujours correct, d'autant plus que les opérations en vrac sont généralement moins chères; mais de toute façon - nous devons garder à l'esprit que l'opération de réapprovisionnement est 5 fois plus chère que la simple portion.
Un livre moyen (2 cm * 20 cm * 30 cm) représente 1,5 litre de volume, donc 4000 livres = 6 mètres cubes. Cela devrait convenir à un seul véhicule utilitaire léger moyen. 1 mètre cube de papier pèse 600 kg, 6 m ^ 3 = 3,6 tonnes. Un véhicule utilitaire léger moyen peut transporter environ 1,5 tonne, nous en avons donc besoin de 3. Plus un pour la redondance. Nous avons 15 unités de bibliothèque rafraîchies une fois toutes les 2 semaines, ce qui signifie que ce serait serré dans les délais, nous avons donc besoin d'une voiture de plus.
Et nous ne pensions toujours pas comment et d'où ces voitures déplaceraient les livres, donc notre conception aura également besoin d'entrepôts de fournisseurs et de points de collecte des ordures pour les livres qui ne sont plus populaires ...
Le temps est écoulé. Alors, quelle est la particularité de la question NALSD? L'évolutivité est attendue de toute grande conception de système. Mais dans une interview NALSD, il faut être
précis .
Vous pouvez voir ci-dessus beaucoup d'hypothèses et d'hypothèses, mais tous les calculs étaient basés sur des nombres précédemment effectués. J'ai également essayé d'expliquer comment obtenir le bon numéro, mais il est facile de se fatiguer / de s'ennuyer et de manquer de le faire. De plus, il est facile de s'en tenir à un certain nombre de votre mémoire, sans fournir une bonne explication de ses raisons ... Mais puisque la conception est très spécifique, si vous faites une erreur pour n'importe quel nombre, vous pouvez changer le nombre et recalculer le reste.
Je me souviens encore comment au cours de mon entretien NALSD, je suis resté avec des IOPS d'un seul disque dur égal à 600, juste parce que j'avais récemment travaillé sur l'optimisation d'un tableau RAID, où tout le tableau avait 600 IOPS ... L'intervieweur était légèrement surpris: 600 IOPS par conduire? : DPendant l'entrevue, n'importe laquelle de vos hypothèses et suppositions pourrait être corrigée par l'intervieweur. De plus, l'intervieweur pourrait ajouter des contraintes supplémentaires (que vous avez oubliées, que vous ne connaissiez pas, que vous n'avez pas posées ou simplement pour ajuster la tâche parce qu'elles aimeraient ou pensent que c'est une meilleure façon de continuer). Puisque vous opérez uniquement sur des nombres spécifiques, cela nécessiterait juste de petites mises à jour des nombres suivant les équations déjà données.
Si la correction d'une hypothèse nécessite une refonte complète du système, c'est soit une erreur de conception, soit une correction incorrecte, soit la nouvelle hypothèse nous fait dépasser l'applicabilité de la conception (et ce n'est pas si rare dans la vie réelle). Il est important de ne pas manquer ce fait: vous devez valider les chiffres que vous obtenez, pour vous assurer qu'ils sont réalistes, à la fois pendant la conception et après toute correction.
En tant que SRE, nous devons penser à l'évolutivité des systèmes réels dans les limites des limitations matérielles réelles. Il pourrait y avoir un bel
algorithme qui échange une gigantesque complexité temporelle en une certaine quantité de RAM ... Mais encore, 1PiB de RAM pour 1 CPU n'est pas quelque chose que nous pouvons construire aujourd'hui. Donc, si nous avons 1 PiB de RAM, nous avons également environ 10k CPU. Ou 20k. Ou même 30k. Cela signifie que nous devons nous concentrer sur l'optimum réel (local), accessible aujourd'hui dans la réalité, et non l'optimum global accessible dans des conditions idéales.
Vous ne devriez pas vous souvenir de chiffres précis, mais vous devriez pouvoir appliquer des règles empiriques pour obtenir des ordres de grandeur. Comme, les IOPS: le disque dur est d'environ 100s, le SSD environ 100s milliers. Mais ces centaines de milliers viennent avec une différence de prix entre le disque dur et le SSD, comme 1: 3 ou 1: 4. C'est également ignorer tout ce qui se passe autour: l'espace rack, les lames pour les disques, les ports réseau et d'autres choses, qui ne sont plus bon marché une fois que vous travaillez à l'échelle de la péta et de l'ex.
Maintenant, installez-vous confortablement dans votre fauteuil, détendez-vous et essayez de concevoir un système de croissance et de livraison d'œufs de poule frais sur abonnement.