Mga networker (hindi) kailangan

Sa oras ng pagsulat na ito, ang paghahanap sa isang sikat na site ng trabaho para sa pariralang "Network Engineer" ay nagbigay ng humigit-kumulang tatlong daang bakante sa buong Russia. Para sa paghahambing, ang paghahanap para sa pariralang "system administrator" ay nagbabalik ng halos 2.5 libong mga bakante, at "DevOps engineer" - halos 800.

Nangangahulugan ba ito na ang mga networker ay hindi na kailangan sa mga araw ng mga nanalong ulap, docker, kubernetis at ang lahat ng mga pampublikong Wi-Fi?
Alamin natin ito (mga)

Magkakilala tayo. Ang pangalan ko ay Alexey, at ako ay isang networker.

Mahigit 10 taon na akong gumagawa ng networking at nagtatrabaho sa iba't ibang *nix system sa loob ng mahigit 15 taon (nagkaroon ako ng pagkakataong pumili ng parehong Linux at FreeBSD). Nagtrabaho ako sa mga operator ng telecom, malalaking kumpanya, na itinuturing na mga "enterprise", at kamakailan ay nagtatrabaho ako sa "bata at matapang" na fintech, kung saan ang mga ulap, devops, kubernetes at iba pang nakakatakot na salita na tiyak na magpapasaya sa akin at sa aking mga kasamahan. hindi kailangan. Ilang araw. Maaaring.

disclaimer: "Sa ating buhay, hindi lahat, palagi at saanman, ngunit isang bagay, kung minsan sa mga lugar" (c) Maxim Dorofeev.

Ang lahat ng nakasulat sa ibaba ay maaari at dapat isaalang-alang na personal na opinyon ng may-akda, hindi inaangkin na ang tunay na katotohanan, at maging isang ganap na pag-aaral. Ang lahat ng mga character ay kathang-isip, ang lahat ng mga pagkakataon ay random.

Maligayang pagdating sa aking mundo.

Saan ka makakahanap ng mga networker?

1. Mga operator ng telecom, mga kumpanya ng serbisyo at iba pang mga integrator. Ang lahat ay simple: ang network para sa kanila ay isang negosyo. Direkta silang nagbebenta ng koneksyon (mga operator) o nagbibigay ng mga serbisyo para sa paglulunsad/pagpapanatili ng mga network ng kanilang mga customer.

Maraming karanasan dito, ngunit hindi gaanong pera (maliban kung ikaw ay isang direktor o isang matagumpay na sales manager). At gayon pa man, kung gusto mo ng mga network, at ikaw ay nasa simula pa lamang ng iyong paglalakbay, ang isang karera sa pagsuporta sa ilang hindi masyadong malaking operator ay, kahit na ngayon, ay isang perpektong panimulang punto (lahat ay napaka-scripted sa mga pederal, at doon ay maliit na puwang para sa pagkamalikhain). Buweno, ang mga kuwento tungkol sa katotohanang posibleng lumago mula sa isang inhinyero na naka-duty sa loob ng ilang taon tungo sa isang C-level manager ay medyo totoo rin, bagaman bihira, para sa mga malinaw na dahilan. Laging kailangan ng personnel, kasi may turnover pa. Ito ay parehong mabuti at masama sa parehong oras - palaging may mga bakante, sa kabilang banda - kadalasan ang mga pinaka-aktibo/matalino ay mabilis na ma-promote o pumunta sa iba, "mas maiinit" na mga lugar.

2. May kondisyong "enterprise". Hindi mahalaga kung ang kanyang pangunahing aktibidad ay nauugnay sa IT o hindi. Ang pangunahing bagay ay mayroon itong sariling departamento ng IT, na nakikibahagi sa pagtiyak sa pagpapatakbo ng mga panloob na sistema ng kumpanya, kabilang ang mga network sa mga tanggapan, mga channel ng komunikasyon sa mga sangay, atbp. Ang mga function ng isang network engineer sa naturang mga kumpanya ay maaaring "part-time" na ginagampanan ng isang system administrator (kung ang network infrastructure ay maliit, o isang panlabas na contractor ay nakikibahagi dito), at ang network manager, kung siya ay umiiral pa, ay maaaring sabay na tumingin sa telephony at SAN (hindi nuacho). Nagbabayad sila sa iba't ibang paraan - ito ay lubos na nakasalalay sa margin ng negosyo, ang laki ng kumpanya at ang istraktura. Nagtatrabaho ako pareho sa mga kumpanya kung saan ang mga cisco ay regular na "nakakarga sa mga bariles", at sa mga kumpanya kung saan ang network ay binuo mula sa mga dumi, stick at asul na electrical tape, at ang mga server ay hindi na-update, humigit-kumulang, kailanman (kinakailangang sabihin na mayroong ay wala ring mga reserba). Mayroong mas kaunting karanasan dito, at ito ay halos tiyak na nasa lugar ng isang hard vendor-lock, o "kung paano gumawa ng isang bagay mula sa wala". Sa personal, tila boring sa akin doon, kahit na maraming mga tao ang gusto nito - ang lahat ay medyo nasusukat at mahuhulaan (kung pinag-uusapan natin ang tungkol sa mga malalaking kumpanya), "dorah-bajato", atbp. Hindi bababa sa isang beses sa isang taon, sinabi ng ilang pangunahing vendor na nakagawa sila ng isa pang mega-super-duper system na nag-o-automate ng lahat ngayon at lahat ng mga administrator ng system at networker ay maaaring ma-overclocked, na nag-iiwan sa isang mag-asawa na pindutin ang mga pindutan sa isang magandang interface. Ang katotohanan ay, kahit na balewalain natin ang halaga ng solusyon, ang mga networker ay hindi pupunta kahit saan mula doon. Oo, posible na sa halip na console ay magkakaroon muli ng isang web interface (ngunit hindi isang tiyak na piraso ng bakal, ngunit isang malaking sistema na namamahala sa sampu at daan-daang mga naturang piraso ng bakal), ngunit ang kaalaman sa "kung paano gumagana ang lahat sa loob ” kakailanganin pa rin.

3. Mga kumpanya ng produkto, na ang tubo ay nagmumula sa pagbuo (at, madalas, pagpapatakbo) ng ilang software o platform - ang parehong produkto. Kadalasan sila ay maliliit at maliksi, malayo pa sila sa sukat ng mga negosyo at kanilang burukratisasyon. Dito matatagpuan ang mga parehong devops, cubers, dockers at iba pang kakila-kilabot na mga salita, na tiyak na gagawin ang network at mga network engineer na isang hindi kinakailangang panimula.

Paano naiiba ang isang manager ng network sa isang sysadmin?

Sa pag-unawa ng mga tao na hindi mula sa IT - wala. Pareho silang tumingin sa itim na screen at sumulat ng ilang mga spells, kung minsan ay nagmumura ng mahina.

Sa pag-unawa ng mga programmer - marahil ang lugar ng paksa. Ang mga Sysadmin ay nangangasiwa ng mga server, ang mga networker ay nangangasiwa ng mga switch at router. Minsan ang admin ay masama, at lahat ay nahuhulog para sa lahat. Well, in case of any strange, networkers din ang may kasalanan. Just because fuck you, kaya lang.

Sa katunayan, ang pangunahing pagkakaiba ay ang diskarte sa trabaho. Marahil, ito ay sa mga networker na higit sa lahat mayroong mga tagasuporta ng diskarte na "It works - don't touch it!". Karaniwang magagawa mo ang isang bagay (sa loob ng isang vendor) sa isang paraan lamang, ang buong pagsasaayos ng kahon - narito ito, sa iyong palad. Ang gastos ng isang error ay mataas, at kung minsan ay napakataas (halimbawa, kailangan mong maglakbay ng ilang daang kilometro upang i-reboot ang router, at sa oras na ito ilang libong tao ang walang komunikasyon - isang sitwasyon na karaniwan para sa isang telecom operator. ).

Sa palagay ko, ito ang dahilan kung bakit ang mga inhinyero ng network, sa isang banda, ay lubos na nag-uudyok para sa katatagan ng network (at ang mga pagbabago ay ang pangunahing kaaway ng katatagan), at pangalawa, ang kanilang kaalaman ay mas malalim kaysa sa lawak (hindi mo kailangan upang ma-configure ang dose-dosenang iba't ibang mga demonyo , kailangan mong malaman ang mga teknolohiya at ang kanilang pagpapatupad mula sa isang partikular na tagagawa ng kagamitan). Kaya naman ang system administrator, na nag-google kung paano magrehistro ng vlan sa isang tsiska, ay hindi pa isang network manager. At malamang na hindi niya magagawang epektibong suportahan (pati na rin ang pag-troubleshoot) ng mas kumplikadong network.

Ngunit bakit kailangan mo ng network manager kung mayroon kang hoster?

Para sa dagdag na pera (at kung ikaw ay isang napakalaki at minamahal na kliyente, marahil kahit na libre, "bilang isang kaibigan"), iko-configure ng mga inhinyero ng data center ang iyong mga switch upang umangkop sa iyong mga pangangailangan, at, marahil, kahit na tumulong na itaas ang isang interface ng BGP sa mga provider (kung mayroon kang sariling subnet ng mga ip address na iaanunsyo).

Ang pangunahing problema ay ang data center ay hindi ang iyong IT department, ito ay isang hiwalay na kumpanya na ang layunin ay kumita. Kasama sa gastos mo bilang isang kliyente. Ang data center ay nagbibigay ng mga rack, nagbibigay sa kanila ng kuryente at malamig, at nagbibigay din ng ilang "default" na koneksyon sa Internet. Batay sa imprastraktura na ito, maaaring i-co-locate ng data center ang iyong kagamitan (colocation), magrenta sa iyo ng server (dedikadong server), o magbigay ng pinamamahalaang serbisyo (halimbawa, OpenStack o K8s). Ngunit ang negosyo ng data center (kadalasan) ay hindi ang pangangasiwa ng imprastraktura ng customer, dahil ang prosesong ito ay sa halip labor-intensive, hindi maganda ang automated (at sa isang normal na data center lahat ay awtomatiko), pinag-isang mas masahol pa (ang bawat kliyente ay indibidwal) at sa pangkalahatan ay puno ng mga paghahabol ("sabihin mo sa akin na ang server ay na-set up, at ngayon ay nag-crash ito, kasalanan mo ang lahat!!!111"). Samakatuwid, kung tutulungan ka ng hoster sa isang bagay, susubukan niyang gawin itong simple at "condo" hangga't maaari. Para sa ito ay mahirap gawin - hindi kumikita, hindi bababa sa mula sa punto ng view ng mga gastos sa paggawa ng mga inhinyero ng napaka-hoster na ito (ngunit ang mga sitwasyon ay naiiba, tingnan ang disclaimer). Hindi ito nangangahulugan na ang host ay kinakailangang gawin ang lahat ng masama. Ngunit hindi ito isang katotohanan na gagawin niya kung ano ang talagang kailangan mo.

Mukhang medyo halata ang bagay, ngunit ilang beses sa aking pagsasanay nalaman ko ang katotohanan na ang mga kumpanya ay nagsimulang umasa sa kanilang hosting provider nang kaunti pa kaysa sa nararapat, at hindi ito humantong sa anumang mabuti. Kinailangan ng mahabang panahon upang ipaliwanag nang detalyado na walang SLA ang sasagot sa mga pagkalugi sa downtime (may mga pagbubukod, ngunit kadalasan ito ay napaka, VERY mahal para sa kliyente) at ang hoster ay hindi alam kung ano ang nangyayari sa imprastraktura ng mga customer. (maliban sa mga pangkalahatang tagapagpahiwatig). At ang hoster ay hindi rin gumagawa ng mga backup para sa iyo. Mas malala pa ang sitwasyon kung mayroon kang higit sa isang hoster. Sa kaso ng anumang mga problema sa pagitan nila, tiyak na hindi nila malalaman para sa iyo kung ano ang naging mali.

Sa totoo lang, ang mga motibo dito ay eksaktong kapareho ng kapag pumipili ng "sariling koponan ng mga admin vs outsourcing". Kung ang mga panganib ay kinakalkula, ang kalidad ay nababagay, at ang negosyo ay hindi tututol - bakit hindi subukan ito. Sa kabilang banda, ang network ay isa sa mga pinakapangunahing layer ng imprastraktura, at halos hindi sulit na ibigay ito sa mga tagalabas kung sinusuportahan mo na ang lahat ng iba pa.

Kailan mo kailangan ng networker?

Dagdag pa, tututuon tayo sa mga modernong kumpanya ng produkto. With operators and enterprises, everything is plus or minus clear - kaunti lang ang nagbago doon nitong mga nakaraang taon, at kailangan ang mga networker doon noon, kailangan na sila ngayon. Ngunit sa mga napaka "bata at matapang" na mga bagay ay hindi gaanong simple. Kadalasan ay inilalagay nila ang kanilang imprastraktura nang buo sa mga ulap, kaya hindi na nila kailangan ng mga admin, maliban sa mga admin ng parehong mga ulap, siyempre. Ang imprastraktura, sa isang banda, ay medyo simple sa disenyo nito, sa kabilang banda, ito ay mahusay na awtomatiko (ansible / puppet, terraform, ci / cd ... well, alam mo na). Ngunit kahit dito may mga sitwasyon na hindi mo magagawa nang walang network engineer.

Halimbawa 1, classic

Ipagpalagay na ang isang kumpanya ay nagsisimula sa isang server na may pampublikong ip-address, na matatagpuan sa data center. Tapos may dalawang server. At higit pa ... Maaga o huli, may pangangailangan para sa isang pribadong network sa pagitan ng mga server. Dahil ang "panlabas" na trapiko ay limitado sa parehong bandwidth (hindi hihigit sa 100Mbps, halimbawa) at sa dami ng na-download / na-upload bawat buwan (iba't ibang mga hoster ang may iba't ibang mga taripa, ngunit ang bandwidth sa labas ng mundo, bilang panuntunan, ay marami. mas mahal kaysa sa isang pribadong network).

Ang hoster ay nagdaragdag ng mga karagdagang network card sa mga server at isinama ang mga ito sa kanilang mga switch sa isang hiwalay na vlan. Lumilitaw ang isang "flat" LAN sa pagitan ng mga server. Komportable!

Ang bilang ng mga server ay lumalaki, ang trapiko sa pribadong network ay lumalaki din - mga backup, replikasyon, atbp. Nag-aalok ang hoster na ilipat ka sa hiwalay na mga switch upang hindi ka makagambala sa ibang mga kliyente, at hindi sila makagambala sa iyo. Ang hoster ay naglalagay ng ilang uri ng mga switch at kahit papaano ay kino-configure ang mga ito - malamang, nag-iiwan ng isang patag na network sa pagitan ng lahat ng iyong mga server. Ang lahat ay gumagana nang maayos, ngunit sa isang tiyak na punto, nagsisimula ang mga problema: ang mga pagkaantala sa pagitan ng mga host ay pana-panahong lumalaki, ang mga log ay nanunumpa sa napakaraming mga arp packet bawat segundo, at ang pentester ay ginahasa ang iyong buong lokal na lugar sa panahon ng pag-audit, na sinira ang isang server lamang.

Ano ang dapat gawin?

Hatiin ang network sa mga segment - mga vlan. I-set up ang sarili mong addressing sa bawat vlan, pumili ng gateway na maglilipat ng trapiko sa pagitan ng mga network. Sa gateway, i-configure ang acl upang paghigpitan ang pag-access sa pagitan ng mga segment, o kahit na maglagay ng hiwalay na firewall sa tabi nito.

Halimbawa 1, ipinagpatuloy

Ang mga server ay konektado sa lokal na lugar na may isang kurdon. Ang mga switch sa mga rack ay sa paanuman ay magkakaugnay, ngunit sa kaganapan ng isang aksidente sa isang rack, tatlo pang kalapit na mga ito ay mahulog. Mayroong mga scheme, ngunit may mga pagdududa tungkol sa kanilang kaugnayan. Ang bawat server ay may sariling pampublikong address, na ibinibigay ng host at nakatali sa rack. Yung. kapag inilipat ang server, kailangang baguhin ang address.

Ano ang dapat gawin?

Ikonekta ang mga server gamit ang LAG (Link Aggregation Group) na may dalawang cord upang lumipat sa rack (kailangan din nilang maging redundant). Ireserba ang mga koneksyon sa pagitan ng mga rack, gawing muli ang mga ito gamit ang isang "bituin" (o ang uso ngayon na CLOS) upang ang pagkawala ng isang rack ay hindi makaapekto sa iba. Piliin ang "central" na mga rack kung saan matatagpuan ang core ng network at kung saan isasama ang iba pang mga rack. Kasabay nito, ayusin ang pampublikong addressing, kumuha mula sa hoster (o mula sa RIR, kung maaari) ng isang subnet, na ikaw mismo (o sa pamamagitan ng host) ay inihayag sa mundo.

Magagawa ba ng isang "regular" na system administrator na walang malalim na kaalaman sa mga network ang lahat ng ito? Hindi ako sigurado. Gagawin ba ito ng host? Marahil ay gagawin ito, ngunit kakailanganin mo ng isang medyo detalyadong TOR, na kakailanganin ding i-compile ng isang tao. at pagkatapos ay suriin na ang lahat ay tapos na nang tama.

Halimbawa 2: Maulap

Ipagpalagay na mayroon kang VPC sa ilang pampublikong cloud. Upang makakuha ng access mula sa opisina o on-prem na bahagi ng imprastraktura patungo sa lokal na network sa loob ng VPC, kailangan mong mag-set up ng koneksyon sa pamamagitan ng IPSec o isang nakalaang channel. Sa isang banda, ang IPSec ay mas mura. hindi na kailangang bumili ng karagdagang hardware, maaari kang mag-set up ng tunnel sa pagitan ng iyong server na may pampublikong address at cloud. Ngunit - mga pagkaantala, limitadong pagganap (dahil kailangang i-encrypt ang channel), at hindi garantisadong koneksyon (dahil ang pag-access ay dumadaan sa regular na Internet).

Ano ang dapat gawin?

Itaas ang koneksyon sa pamamagitan ng isang nakalaang channel (halimbawa, tinatawag itong Direct Connect ng AWS). Upang gawin ito, maghanap ng kasosyong operator na magkokonekta sa iyo, magpasya sa punto ng koneksyon na pinakamalapit sa iyo (kapwa ka sa operator at ang operator sa cloud), at, sa wakas, i-set up ang lahat. Magagawa ba ang lahat ng ito nang walang network engineer? Sigurado, oo. Ngunit kung paano mag-troubleshoot nang wala ito sa kaso ng mga problema ay hindi na malinaw.

At maaaring may mga problema din sa availability sa pagitan ng mga ulap (kung mayroon kang multicloud) o mga problema sa mga pagkaantala sa pagitan ng iba't ibang rehiyon, atbp. Siyempre, ngayon ay maraming mga tool na nagpapataas ng transparency ng kung ano ang nangyayari sa cloud (ang parehong Thousand Eyes), ngunit ang lahat ng ito ay mga tool sa network engineer, at hindi isang kapalit.

Maaari akong mag-sketch ng isang dosenang higit pang mga halimbawa mula sa aking pagsasanay, ngunit sa palagay ko ay malinaw na sa isang koponan, simula sa isang tiyak na antas ng pag-unlad ng imprastraktura, dapat mayroong isang tao (o mas mabuti, higit sa isa) na nakakaalam kung paano ang network gumagana, maaaring i-configure ang kagamitan sa network at harapin ang mga problema kung lumitaw ang mga ito. Maniwala ka sa akin, may gagawin siya

Ano ang dapat malaman ng isang networker?

Hindi naman talaga kailangan (at kahit minsan ay nakakapinsala) para sa network engineer na makitungo lamang sa network at wala nang iba pa. Kahit na hindi namin isaalang-alang ang opsyon sa isang imprastraktura na halos nabubuhay sa isang pampublikong ulap (at, anuman ang maaaring sabihin ng isa, ito ay nagiging mas at mas sikat), at kumuha, halimbawa, sa premise o pribadong ulap, kung saan lamang "kaalaman sa antas ng CCNP "Hindi ka aalis.

Bilang karagdagan sa, sa katunayan, mga network - kahit na mayroong isang walang katapusang larangan para sa pag-aaral, kahit na tumutok ka lamang sa isang direksyon (mga network ng provider, negosyo, data center, Wi-Fi ...)

Siyempre, marami sa inyo ang maaalala na ngayon ang Python at iba pang "network automation", ngunit ito ay kinakailangan lamang, ngunit hindi sapat na kondisyon. Upang ang isang network engineer ay "matagumpay na makasali sa team", kailangan niyang magsalita sa parehong wika sa parehong mga developer at kapwa admin / devops. Ano ang ibig sabihin nito?

• magagawang hindi lamang gumana sa Linux bilang isang gumagamit, ngunit pinangangasiwaan din ito, hindi bababa sa antas ng isang sysadmin-junior: i-install ang kinakailangang software, i-restart ang isang nahulog na serbisyo, magsulat ng isang simpleng systemd-unit.
• Unawain (kahit sa mga pangkalahatang termino) kung paano gumagana ang network stack sa Linux, kung paano gumagana ang network sa mga hypervisors at container (lxc / docker / kubernetes).
• Siyempre, makatrabaho ang ansible/chef/puppet o ibang SCM system.
• Ang isang hiwalay na linya ay dapat na nakasulat tungkol sa SDN at mga network para sa mga pribadong ulap (halimbawa, TungstenFabric o OpenvSwitch). Ito ay isa pang malaking piraso ng kaalaman.

Sa madaling salita, inilarawan ko ang isang tipikal na T-shape specialist (tulad ng uso ngayon na sabihin). Mukhang hindi na bago, gayunpaman, ayon sa karanasan ng mga panayam, hindi lahat ng mga inhinyero ng network ay maaaring magyabang ng kaalaman ng hindi bababa sa dalawang paksa mula sa listahan sa itaas. Sa pagsasagawa, ang kakulangan ng kaalaman "sa mga kaugnay na lugar" ay nagpapahirap hindi lamang sa pakikipag-usap sa mga kasamahan, kundi pati na rin upang maunawaan ang mga kinakailangan na ipinapataw ng negosyo sa network bilang ang pinakamababang antas ng imprastraktura ng proyekto. At kung wala ang pag-unawang ito, nagiging mas mahirap na makatwirang ipagtanggol ang iyong pananaw at "ibenta" ito sa negosyo.

Sa kabilang banda, ang mismong ugali ng "pag-unawa sa kung paano gumagana ang sistema" ay nagbibigay sa mga networker ng napakahusay na kalamangan sa iba't ibang "mga heneral" na nakakaalam tungkol sa mga teknolohiya mula sa mga artikulo sa Habré/medium at telegrama na mga chat, ngunit walang ganap na ideya kung anong mga prinsipyo ito o gumagana ang software na iyon. At ang kaalaman sa ilang mga regularidad, tulad ng alam mo, ay matagumpay na pinapalitan ang kaalaman ng maraming mga katotohanan.

Mga konklusyon, o simpleng TL;DR

1. Ang isang administrator ng network (tulad ng isang DBA o isang VoIP engineer) ay isang espesyalista ng isang medyo makitid na profile (hindi tulad ng mga sysadmins / devops / SRE), ang pangangailangan para sa kung saan ay hindi kaagad lumitaw (at maaaring hindi lumitaw nang mahabang panahon, sa katunayan) . Ngunit kung ito ay bumangon, malamang na hindi ito mapapalitan ng kadalubhasaan sa labas (outsourcing o ordinaryong generalist administrator, "na nangangalaga rin sa network"). Ang medyo nakakalungkot ay ang pangangailangan para sa mga naturang espesyalista ay maliit, at, sa kondisyon, sa isang kumpanya na may 800 programmer at 30 devops / admin, maaari lamang magkaroon ng dalawang networker na ganap na ginagawa ang kanilang trabaho. Yung. ang merkado noon at napakaliit, at mas mababa pa na may magandang suweldo.
2. Sa kabilang banda, dapat malaman ng isang mahusay na networker sa modernong mundo hindi lamang ang mga network mismo (at kung paano i-automate ang kanilang configuration), kundi pati na rin kung paano nakikipag-ugnayan sa kanila ang mga operating system at software, na tumatakbo sa mga network na ito. Kung wala ito, napakahirap na maunawaan kung ano ang hinihiling ng mga kasamahan mula sa iyo at ihatid (makatuwirang) ang iyong mga kagustuhan / kinakailangan sa kanila.
3. Walang ulap, computer lang ng iba. Kailangan mong maunawaan na ang paggamit ng pampubliko / pribadong ulap o ang mga serbisyo ng mga tagapagbigay ng pagho-host na "na ginagawa ang lahat para sa iyo" ay hindi nagpapawalang-bisa sa katotohanan na ang iyong aplikasyon ay gumagamit pa rin ng network, at ang mga problema dito ay makakaapekto sa pagpapatakbo ng iyong aplikasyon. . Ang iyong pinili ay kung saan matatagpuan ang competence center, na siyang magiging responsable para sa network ng iyong proyekto.

Pinagmulan: www.habr.com